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Do You Speak Martian? 


There are an abundance of books on computer architectures, computer 
logic, and computer mathematics, and most of these works discuss vari¬ 
ous techniques for representing and manipulating numbers inside com¬ 
puters. Sadly, however, it appears that the majority of these tomes are 
written by visitors from the planet Mars, whose keen understanding of 
higher mathematics is somewhat offset by their limited grasp of the 
English language. 

“Say ifs not so!” you cry, but the proof is irrefutable. When was the 
last time you waded through a book on computer mathematics without 
your brain overheating? Much like reading Being and Nothingness by the 
famous French philosopher Jean Paul Sartre, one could mull over many 
of these cryptic masterpieces until the end of time without gaining so 
much as the faintest clue as to what was in their authors’ minds. 

This is why we have been moved to write this modest attempt at in¬ 
troducing the basics of computer arithmetic in words we can all under¬ 
stand. An impossible task, some may say, but we dare to fly in the face of 
conventional wisdom. Now, read on. . . . 
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The simplest schoolboy is now familiar with 
facts for which Archimedes would have 
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1 In this chapter we will learn 
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• The sock color of choice for the discerning 
Viking warrior 

• Why this book is so cool 

• That there are jobs awaiting time-travelers 

• Some “stuff’ about calculators 

• Why this chapter is numbered “0” 
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2 WHY THIS BOOK IS SO COOL 


Fearsome Warriors or Slaves 
to Fashion? 


Many of us are used to thinking of the Vikings as fearsome warriors (this 
isn’t your Mother’s math book!) who descended from the northlands and 
rampaged and pillaged across Europe. These formidable fighters are pop¬ 
ularly believed to have laughed at danger and scoffed at the elements, so 
the recent archeological discovery that many Vikings wore red woolly 
socks is, to many of us, somewhat disconcerting. However, we digress. . . 

This Book Is Cool Beoause . . . 


This book really is cool because, together, we are going to discover all 
sorts of interesting snippets of knowledge, tidbits of data, and nuggets of 
trivia, all bundled together with a tremendous amount useful informa¬ 
tion as to how computers and calculators perform their magic; and it 
isn’t going to make our heads hurt at all! 

Experts (the authors’ mothers in this case) agree that one of the 
best ways to learn something and remember it afterward is by means of 
hands-on experience, which you are poised to gain in huge dollops by 
using the virtual microcomputer/calculator that you’ll find on the CD- 
ROM accompanying this book. 

As one rocket scientist^ who reviewed this manuscript told the au¬ 
thors: “The combination of this book and its associated virtual computer 
is fantastic! Experience over the last 50 years has shown me that there’s 
only one way to truly understand how computers work, and that is to 
learn one computer and its instruction set, no matter how simple or 
primitive, from the ground up. Once you fully comprehend how that 
simple computer functions, you can easily extrapolate to more complex 
machines.” However, once again, we digress. . . 

Jobs Abound for Time-Travelers 


Today, most of us are extremely familiar with using numbers to perform 
simple tasks such as addition, subtraction, multiplication, and division. 

^Honestly. Huntsville, Alabama, U.S.A. (where the authors live) is known as the Space 
Capital of America, and it’s difficult to take even a short strolling without bumping into 
at least one rocket scientist. 
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Due to the fact that we are so intimate with these concepts, we tend to 
forget the tremendous amounts of mental effort that have been expended 
by so many folks over the millennia to raise us to our present level of un¬ 
derstanding. 

In the days of yore, when few people even knew how to count be¬ 
yond the number of fingers on their hands,^ anyone who was capable of 
performing relatively rudimentary mathematical operations could easily 
achieve a position of power and standing in the community. 

If you could predict an eclipse, for example, you were obviously 
someone to be reckoned with (especially if it actually came to pass). Sim¬ 
ilarly, if you were a warrior chieftain, it would be advantageous to know 
how many fighting men and women you had at your command, and the 
person who could provide you with this vital information would obvi¬ 
ously rank high on your summer-solstice card list.^ 

So, we can all rest easy in our beds at night, secure in the knowledge 
that, should we ever be presented with the occasion to travel back 
through time, there would be numerous job opportunities awaiting our 
arrival. However (you guessed it), we digress. . . 


Calculators Then and Now 


Every now and then, strange and wonderful mechanisms from antiquity 
are discovered. In 1900, for example, a device of unknown purpose con¬ 
taining numerous gear wheels forming a sophisticated mechanism dating 
from 2200 BC was discovered in a shipwreck close to the tiny Greek is¬ 
land of Antikythera. This contraption, which is now known as the An- 
tikythera Mechanism or the Antikythera Calculator, was created during 
the early years of the Hellenistic Period, a golden age during which sci¬ 
ence and art flourished in ancient Greece. 

In many cases, objects like this prompt speculation that our ante¬ 
diluvian ancestors were the creators of complex mechanical calculators 
with which they could perform mathematical operations such as addi¬ 
tion, subtraction, multiplication, and division. In reality, however, the 
concept of zero (0) as representing a true quantity in a place-value num- 

^Sometimes, fingers and toes in the case of societies that employed vigesimal (base-20) 
numbering systems. 

^You wouldn’t have a Christmas card list, because Christmas cards weren’t invented until 
1843. (Try finding this tasty morsel of trivia in another computer book!) 
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The invention of zero and negative numbers, the use of tally sticks and the abacus, the origin of 
logic machines, calculators, and computers; and a wealth of other topics are discussed in more detail in “The 
History of Calculators, Computers, and Other Stuff’ provided on the CD-ROM accompanying this book. 
See Appendix D for more details on additional resources, including this history. 


ber system didn’t appear until around 600 AD in India. Without the no¬ 
tion of zero in this context, it is really not possible to create a mechanical 
calculator in any form we would recognize. 

This is not to say that these ancient mechanisms were not incredi¬ 
bly cunning and refined. However, such instruments were probably de¬ 
signed to measure things or to track time in one way or another; for ex¬ 
ample, to help in predicting the seasons and the activities of celestial 
objects like the sun, moon, planets, and constellations. 

On the other hand, we might well wonder why, after the idea of 
zero as an actual number entered the scene, it took so long to actually in¬ 
vent a true mechanical calculator. Of course it’s fair to say that Europe 
was undergoing a period of stagnation in art, literature, and science 
called the Dark Ages.'* However, there were many brilliant minds in the 
Byzantine Empire and the Arabic, Chinese, Indian, and Persian cultures 
(to name but a few) that would almost certainly have been up to the task. 

Be this as it may, the first true mechanical calculators of which we 
are aware were the Calculating Clock (1623), which was created by the 
German astronomer and mathematician Wilhelm Schickard 
(1592-1635); the Pascaline or Arithmetic Machine (1642), which was the 
inspiration of the French mathematician, physicist, and theologian Blaise 
Pascal (1623-1662); and the Step Reckoner (1694), which was the brain¬ 
child of a German Baron called Gottfried von Leibniz (1646-1716). 

Countless mechanical calculating machines emerged to see the light 
of day over the next few hundred years, but these were all largely based 
on the underlying principles established by Schickard, Pascal, and Leib¬ 
niz. However, “the times they were a’changin,” as they say. The inven¬ 
tion of the transistor in 1947 and the integrated circuit (silicon chip) in 
1958 paved the way for an entirely new class of calculating devices. 

'‘Some pundits equate the Dark Ages with the Middle Ages (the period in European his¬ 
tory between Antiquity and the Renaissance, often dated from 476 AD to 1453 AD), 
whereas others regard the Dark Ages as encompassing only the early portion of the 
Middle Ages. 
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The first experimental model of an electronic pocket calculator was 
created by Texas Instruments in 1966.^ This was followed in 1970/1971 
by the first commercially available unit, a portable (hand-held) printing 
calculator called the Pocketronic. Created as a joint effort by Texas In¬ 
struments and Cannon, and priced at $150 (which was a lot of money at 
the time), this four-function device could add, subtract, multiply, and 
divide. 

Today, of course, it’s possible to purchase pocket calculators that 
boast enough computing power to guide a rocket to the moon, and 
cheap and cheerful versions are now so ubiquitous that it’s not uncom¬ 
mon to find them as giveaways in boxes of breakfast cereal. However 
(believe it or not), we digress. . . 

Deja Vu (Didn’t Someone Just 
Say That?) 

Whether they are aware of it or not, the average person in the developed 
world comes into contact with dozens or hundreds of electronic calculat¬ 
ing, computing, and controlling machines every day. These devices toil 
away, performing countless mathematical operations, but very few of us 
actually know what they are doing or, perhaps more importantly, how 
they are doing it. 

Consider your own pocket calculator, for example. When you mul¬ 
tiply two numbers like 36.984562 and 79.386431 together and you are 
presented with the result, you may well assume that the answer is correct, 
but just how correct is it? and is it correct enough? The accuracy and preci¬ 
sion (as we will discover, these are two different things) required by an 
accountant and a rocket scientist may be poles apart. 

As we noted earlier, in the not-so-distant past, anyone who was ca¬ 
pable of performing relatively rudimentary mathematical operations 
could easily achieve a position of power and standing in the community. 
Well, we are in danger of finding ourselves in a deja vu situation, because 
knowledge is power, and very few folks actually have any clue as to what 
is going on behind the scenes with regard to the way in which computers 
and calculators perform even simple operations. 

^This machine is now preserved at the Nationai Museum of American History (a part of 
the Smithsonian Institution) in Washington, DC, U.S.A. 
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But fear not, because there’s nothing to fear but fear itself You can 
turn that frown upside down into a smile, because we are going to ex¬ 
plain just how computers and calculators perform their magic. The really 
“cool beans” part of all of this is the virtual microcomputer/calculator on 
the CD-ROM accompanying this book. When you first launch this DIY 
Calculator application on your home computer (PC) and click the but¬ 
tons on the calculator interface nothing will happen. But wait, there’s 
more! We are going to guide you through the process of creating your 
very own program to make the calculator function as required. On the 
way, we wiU discover all sorts of interesting things that wiU leave us grin¬ 
ning with delight and gasping for more. However, we digress.. . 


Why Is this Chapter Numbered “0”? 

Computer programmers and engineers typically start counting, indexing, 
and referencing things from zero.® Thus, in order to keep in the spirit 
of things, we decided to follow the same convention with our chapter 
numbers. 

However, let us digress no more. You are poised on the brink of 
discovering all manner of weird and wonderful things, so proceed imme¬ 
diately to Chapter 1 and let the fun begin! 


Except where such interpretation is inconsistent with the context, the singular shall be deemed to 
include the plural, the masculine shall be deemed to include the feminine, and the spelling and punctuation 
shall be deemed to be correct! 


®The reasons for this—and related conventions—will become apparent as we wend our 
way through the topics in this book. 
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1 In this chapter we will learn about: 

C • Counting on fingers and toes 

- • Place-value number systems 

) • Using powers or exponents 

I. • The binary number system 

C • The hexadecimal number system 

• Counting in the binary and hexadecimal systems 

• Using wires to represent numbers 
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8 INTRODUCING BINARY AND HEXADECIMAL NUMBERS 


Why Do We Need to Know this Stuff? 

The number system with which we are most familiar is the decimal sys¬ 
tem, which is based on ten digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. As we shall 
soon discover, however, it’s easier for electronic systems to work with 
data that is represented using the binary number system, which compris¬ 
es only two digits: 0 and 1. 

Unfortunately, it’s difficult for humans to visualize large values pre¬ 
sented as strings of Os and Is. Thus, as an alternative, we often use the 
hexadecimal number system, which is based on sixteen digits that we rep¬ 
resent by using the numbers 0 through 9 and the letters A through F. 

Familiarity with the binary and hexadecimal number systems is 
necessary in order to truly understand how computers and calculators 
perform their magic. In this chapter, we will discover just enough to 
make us dangerous, and then we’ll return to consider number systems 
and representations in more detail in Chapters 4, 5, and 6. 


Counting on Fingers and Toes 

The first tools used as aids to calculation were almost certainly man’s 
own fingers. It is no coincidence, therefore, that the word “digit” is used 
to refer to a finger (or toe) as well as a numerical quantity. As the need 
grew to represent greater quantities, small stones or pebbles could be 
used to represent larger numbers than could fingers and toes. These had 
the added advantage of being able to store intermediate results for later 
use. Thus, it is also no coincidence that the word “calculate” is derived 
from the Latin word for pebble. 

Throughout history, humans have experimented with a variety of 
different number systems. For example, you might use one of your 
thumbs to count the finger joints on the same hand (1, 2, 3 on the index 
finger; 4, 5, 6 on the next finger; up to 10, 11, 12 on the little finger). 
Based on this technique, some of our ancestors experimented with base- 
12 systems. This explains why we have special words like dozen, meaning 
“twelve,” and gross, meaning “one hundred and forty-four” (12 x 12 = 
144). The fact that we have 24 hours in a day (2 x 12) is also related to 
these base-12 systems. 

Similarly, some groups used their fingers and toes for counting, so 
they ended up with base-20 systems. This is why we still have special 
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Truth to tell, the first people to employ their fingers as counting aids didn’t use the digits 0,1, 2, 
and 3. Instead, they started counting at one, as in 1, 2, 3,4, because if all one is doing is counting goats, for 
example, then the concepts of “zero goats” (and “negative goats”) are relatively unimportant. In fact, it was 
not until around 600 AD that the use of zero as an actual value, along with the concept of negative 
numbers, first appeared in India. 


words like score, meaning “twenty.” However, due to the fact that we 
have ten fingers, the number system with which we are most familiar is 
the decimal system, which is based on ten digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 
and 9 (see note). The word decimal is derived from the Latin decam, 
meaning “ten.” As this system uses ten digits, it is said to be base-10 or 
radix-10; the term radix comes from the Latin word meaning “root.” 


Dates in Western books have traditionally been shown in the form 1000 BC or 2001 AD, where BC 
stands for “Before Christ” and AD is an abbreviation of the Latin Ano Domini, meaning “Year of our Lord.” In 
many cases, modern historians now prefer to use BCE, meaning “Before Common Era,” instead of BC; and CE, 
meaning “Common Era,” instead of AD. This preference is based on the fact that BCE and CE aren’t associated 
with any particular religion. However, the BC/AD nomenclature is more familiar to nonhistorians, so that is 
what we are using in this book. 


Place-Value Number Systems 

Consider the concept of Roman numerals, in which I=1,V = 5, X=10, 
L = 50, C = 100, D = 500, M = 1,000, and so forth. Using this scheme, 
XXXV represents 35 (three tens and a five). One problem with this type 
of number system is that over time, as a civilization develops, it tends to 
become necessary to represent larger and larger quantities. This means 
that mathematicians either have to keep on inventing new symbols or 
start using lots and lots of their old ones. But the biggest disadvantage of 
this approach is that it’s painfully difficult to work with (try multiplying 
CLXXX by DDCV and it won’t take you long to discover what we mean). 

An alternative technique is known as a place-value system, in which 
the value of a particular digit depends both on itself and on its position 
within the number. This is the way in which the decimal number system 
works. In this case, each column in the number has a “weight” associated 
with it, and the value of the number is determined by combining each 
digit with the weight of its column (Figure 1-1). 
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Thousands column 
Hundreds column 
Tens column 
Ones column 


t T T t 


6 2 4 9 


T 


T 


▼ 


T 


= (6x 1000) +(2x 100) + (4x 10)+ (9x 1) 
= 6000 + 200 + 40 + 9 

= 6249 


Figure 1-1. Combining digits and column weights in decimal. 


Using Powers or Exponents 

Another way of thinking about this is to use the concept of powers; for 
example, 100 = 10 x 10. This can be written as 10^, meaning “ten to 
the power of two” or “ten multiplied by itself two times.” Similarly, 

1000 = 10 x 10 x 10= 10^ 10,000 = 10 x 10 x 10 x 10= 10^ and so 
forth (Figure 1-2). 

Rather than talking about using powers, some mathematicians pre¬ 
fer to refer to this type of representation as an exponential form. In the 
case of a number like 10^, the number being multiplied (10) is known as 
the base, whereas the exponent (3) specifies how many times the base is to 
be multiplied by itself 


Thousands column 
Hundreds column 
Tens column 
Ones column 


T t T T 


6 2 4 9 


t 


= (6 X 10^) + (2 X 10^) + (4 X 10^) + (9 X 10°) 
= 6000 + 200 + 40 + 9 

= 6249 


Figure 1-2. Using powers of ten. 
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There are a number of points associated with powers (or expo¬ 
nents) that are useful to remember: 

• Any base raised to the power of 1 is the base itself, so 10' = 10. 

• Strictly speaking, a power of 0 is not really part of the series. By 
convention, however, any base to the power of 0 equals 1, so 
10 °= 1 . 

• A value with an exponent of 2 is referred to as the square of the 
number; for example, 3^ = 3 X 3 = 9, where 9 (or 3^) is the square 
of 3. 

• A value with an exponent of 3 is referred to as the cube of the 
number; for example, 3^ = 3x3x3 = 27, where 27 (or 3^) is the 
cube of 3. 

• The square of a whole number (0, 1, 2, 3, 4, etc.) is known as a 
perfect square; for example, 0^ = 0, P = 1, 2^ = 4, 3^ = 9, 4^ = 16, 
5^ = 25, and so on are perfect squares. (The concepts of whole 
numbers and their cousins are introduced in more detail in 
Chapter 4.) 

• The cube of a whole number is known as a perfect cube; for exam¬ 
ple, 0^ = 0, P = 1, 2^ = 8, 3^ = 27, 4^ = 64, 5^ = 125, and so on are 
perfect cubes. 

But we digress. The key point here is that the column weights are 
actually powers of the number system’s base. This will be of particular 
interest when we come to consider other systems. 


Counting in Decimal 

Counting in decimal is easy (mainly because we’re so used to doing it). 
Commencing with 0, we increment the first column until we get to 9, at 
which point we’ve run out of available digits. Thus, on the next count we 
reset the first column to 0, increment the second column to 1, and con¬ 
tinue on our way (Figure 1-3). 

Similarly, once we’ve reached 99, the next count will set the first 
column to 0 and attempt to increment the second column. But the sec¬ 
ond column already contains a 9, so this will also be set to 0 and we’ll in¬ 
crement the third column, resulting in 100, and so it goes. 
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0 

1 

2 

3 

8 

9 

1 0 
1 1 


Figure 1-3. Counting in decimal. 


The Binary Number System 

Unfortunately, the decimal number system is not well suited to the inter¬ 
nal workings of computers. In fact, for a variety of reasons that will be¬ 
come apparent as we progress through this book, it is preferable to use 
the binary (base-2) number system, which employs only two digits: 

0 and 1. 

Binary is a place value system, so each column in a binary number 
has a weight, which is a power of the number system’s base. In this case 
we’re dealing with a base of two, so the column weights will be 2° = 1, 

2^ = 2, 2^ = 4, 2^ = 8, and so forth (Figure 1-4). 


Eights column 
Fours column 
Twos column 
Ones column 


t T t t 


1 1 0 O 2 < 


Binary 

number 


Decimal 

equivalent 


T 


▼ 

T 

(1 x2^) 

+ (1 x2^) + 

(0x2^) 

+ (0x2°) 

(1 x8) 

+ (1x4) + 

(0x2) 

+ (0x1) 

8 

+ 4 + 

0 

+ 0 

12io 





Figure 1-4. Combining digits and column weights in binary. 
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When working with number systems other than decimal, or work¬ 
ing with a mixture of number systems as shown in Figure 1-4, it is com¬ 
mon to use subscripts to indicate whichever base is in use at the time. 

For example, IIOO 2 = 12^0, which means 1100R ,n a r y = 12Decimai- 

Another common alternative is to prefix numbers with a character 
to indicate the base; for example, %1100, where the % indicates a binary 
value. (In fact there are a variety of such conventions, so you need to 
keep your eyes open and your wits about you as you plunge deeper into 
the mire.) Unless otherwise indicated, a number without a subscript or a 
prefix character is generally assumed to represent a decimal value. 

Sometime in the late 1940s, the American chemist turned topologist 
turned statistician John Wilder Tukey realized that computers and the bi¬ 
nary number system were destined to become increasingly important. In 
addition to coining the word “software,” Tukey decided that saying “bi¬ 
nary digit” was a bit of a mouthful, so he started to look for an alternative. 
He considered a variety of options, including hinit and higit, but eventu¬ 
ally settled on hit, which is elegant in its simplicity and is used to this day. 

Binary values of 1IOO 2 and 110011IO 2 are said to be four and eight 
bits wide, respectively. Groupings of four bits are relatively common, so 
they are given the special name of nybble (or sometimes nibble). Similar¬ 
ly, groupings of eight bits are also common, so they are given the special 
name of byte. Thus, “two nybbles make a byte,” which goes to show that 
computer engineers do have a sense of humor (albeit not a tremendously 
sophisticated one). 

Counting in binary 

Counting in binary is even easier than counting in decimal; it just seems 
a little harder if you aren’t familiar with it. As usual, we start counting 
from 0, and then we increment the first column to be 1, at which point 
we’ve run out of all the available digits. Thus, on the next count we reset 
the first column to 0, increment the second column to 1, and proceed on 
our merry way (Figure 1-5). 

Similarly, once we’ve reached II 2 , the next count will set the first 
column to 0 and attempt to increment the second column. But the sec¬ 
ond column already contains a 1, so this will also be set to 0 and we’ll in¬ 
crement the third column, resulting in IOO 2 . (Note that Figure 1-5 does¬ 
n’t require us to use subscripts or special prefix symbols to indicate the 
binary values, because in this case they are obvious from the context.) 
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Binary 

Decimal 

0 

0 

1 

1 

1 0 

2 

1 1 

3 

1 0 0 

4 

1 0 1 

5 

1 1 0 

6 

1 1 1 

7 

10 0 0 

8 


Figure 1-5. Counting in binary. 


Learning your binary "times tables" 

Cast your mind back through the mists of time to those far-off days in 
elementary (junior) school. You probably remember learning your mul¬ 
tiplication “tables” by rote, starting with the “two times table” (“one two 
is two, two twos are four, three twos are six,. ..”) and wending your 
weary way onward and upward to the “twelve times table” (“ten twelves 
are one hundred and twenty, eleven twelves are one hundred and thirty- 
two, and—wait for it, wait for it—twelve twelves are one hundred and 
forty-four”). Phew! 

The bad news is that we need to perform a similar exercise for 
binary: the good news is that, as illustrated in Figure 1-6, we can do the 
whole thing in about five seconds flat! That’s all there is to it. This is the 
only binary multiplication table there is. This really is pretty much as 
complex as it gets! 


Multiplication 

0x0 = 0 
0x1=0 
1x0 = 0 
1x1=1 


Figure 1-6. The binary multiplication table. 
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Using Wires to Represent Numbers 

Today’s digital electronic computers are formed from large numbers of 
microscopic semiconductor switches called transistors, which can be 
turned on and off incredibly quickly (thousands of millions of times 
a second). 


Computers can be constructed using a variety of engineering disciplines, resulting in such beasts as 
electronic, hydraulic, pneumatic, and mechanical systems that process data using analog or digital techniques. 

For the purposes of this book however, we will consider only digital electronic implementations, because these 
account for the overwhelming majority of modern computer systems. 


Transistors can be connected together to form a variety of primitive 
logical elements called logic gates. In turn, large numbers of logic gates 
can be connected together to form a computer. ^ 

It’s relatively easy for electronics engineers to create logic gates that 
can detect, process, and generate two distinct voltage levels.^ For exam¬ 
ple, logic gates circa 1975 tended to use voltage levels of 0 volts and 5 
volts. However, the actual voltage values used inside any particular com¬ 
puter are of interest only to the electronics engineers themselves. All we 
need know is that these two levels can be used to represent binary 0 and 
1, respectively. 

In the “counting in binary” example illustrated in Figure 1-5, 
there was an implication that our table could have continued forever. 
This is because numbers written with pencil and paper can be of any 
size, limited only by the length of your paper and your endurance. By 
comparison, the numbers inside a computer have to be mapped onto a 
physical system of logic gates and wires. For example, a single wire can 
be used to represent only 2^ = 2 binary values (0 and 1), two wires can 
be used to represent 2^ = 2 x 2 = 4 different binary values (00, 01, 10, 
and 11), three wires can be used to represent 2^ = 2x2x2 = 8 differ- 

'Transistors and logic gates are introduced in greater detail in the book Bebop to the 
Boolean Boogie (An Unconventional Guide to Electronics), 2nd edition, by Clive “Max” 
Maxfield ISBN: 0-7506-7543-8. 

^Voltage refers to electrical potential, which is measured in volts. For example, a 9-volt 
battery has more electrical potential than a 3-volt battery. Once again, the concept of 
voltage is introduced in greater detail in Bebop to the Boolean Boogie (An Unconventional 
Guide to Electronics). 
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ent binary values (OOO 2 , OOI 2 , OIO 2 , 0112, IOO 2 , IOI 2 , IIO 2 , and III 2 ), 
and so on. 

The term bus is used to refer to a group of signals that carry similar 
information and perform a common function. In a computer, a bus 
called the data bus is, not surprisingly, used to convey data. 


In this context, the term “data” refers to numerical, logical, or other information presented in a form 
suitable for processing by a computer.For the purposes of this book however, we will consider only digital elec¬ 
tronic implementations, because these account for the overwhelming majority of modern computer systems. 

Actually, “data” is the plural of the Latin datum, meaning “something given.” The plural usage is still common, 
especially among scientists, so it’s not unusual to see expressions like “These data are ...” 

However, it is becoming increasingly common to use “data” to refer to a singular group entity such as 
information. Thus, an expression like “This data is ...” would also be acceptable to a modern audience. 


For the purposes of these discussions, let’s assume that we have a 
data bus comprising eight wires that we wish to use to convey binary 
data. In this case, we can use these wires to represent 2* = 2x2x2x 
2x2x2x2x2 = 256 different combinations of Os and Is. If we 
wished to use these different binary patterns to represent numbers, 
then we might decide to represent decimal values in the range 0 to 255 
(Figure 1-7). For reasons that will be discussed in greater detail in 
Chapter 4, this form of representation is referred to as unsigned 
binary numbers. 

In any numbering system, it is usual to write the most-significant 
digit on the left and the least-significant digit on the right. For exam¬ 
ple, when you see a decimal number such as 825, you immediately as¬ 
sume that the “8” on the left is the most-significant digit (representing 
eight hundred), whereas the “5” on the right is the least-significant dig¬ 
it (representing only five). Similarly, the most-significant binary digit, 
referred to as the most-significant bit (MSB), is on the left-hand side 
of the binary number, whereas the least-significant bit (LSB) is on 
the right. 


The Hexadecimal Number System 

The problem with binary values is that, although we humans are general¬ 
ly good at making sense out of symbolic representations like words and 
numbers, we find it difficult to comprehend the meaning behind long 
strings of Os and Is. For example, the binary value 110011IO 2 doesn’t im- 





THE HEXADECIMAL NUMBER SYSTEM 


17 



0000000 1 ... ( 1 ) 
0000001 0 ... ( 2 ) 
0000001 1 ... (3) 

00000 1 00 ... (4) 


2' = 128s column (MSB) 
2® = 64s column 
2^ = 32s column 
2 “' = 16s column 
2^ = 8s column 
2^ = 4s column 
2^ = 2s column 
2° = Is column (LSB) 


1111110 1 ■ • • (253) 
1 1 1 1 1 1 1 0 ... (254) 
1 1 1 1 1 1 1 1 ... (255) 


Figure 1-7. Using eight wires to represent unsigned binary numbers 
(values in parentheses are decimal equivalents). 


mediately register with most of us, whereas its decimal equivalent of 206 
is much easier to understand. 

Unfortunately (as we shall come to see), translating values between 
binary and decimal can be a little awkward. However, any number sys¬ 
tem with a base that is a power of two (for example, 4, 8, 16, 32, etc.) can 
be easily mapped into its binary equivalent, and vice versa. In the early 
days of computing, it was common for computers to have data busses 
whose widths were whoUy divisible by three (9 bits, 12 bits, 18 bits, and 
so forth). Thus, the octal (base-8) number system became very popular, 
because each octal digit can be directly mapped onto three binary digits 
(bits). More recently, computers have standardized on bus widths that 
are wholly divisible by eight (8 bits, 16 bits, 32 bits, and so forth). For 
this reason, the use of octal has declined and the hexadecimal (base-16) 
number system is now prevalent, because each hexadecimal digit can be 
directly mapped onto four bits. 

As a base-16 system, hexadecimal requires 16 unique symbols, but 
inventing completely new symbols would not be a particularly efficacious 
solution, not the least that we would all have to learn them! Even worse, 
it would be completely impractical to modify every typewriter and com- 
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puter keyboard on the face of the planet. As an alternative, we use a com¬ 
bination of the decimal numbers 0 through 9 and the alpha characters A 
through F (Figure 1-8). 

Counting in hexadecimal 

The rules for counting in hexadecimal are the same as for any place-value 
number system. We commence with 0 and count away until we’ve used up 
all of our symbols (that is, when we get to F); then, on the next count, we 
set the first column to 0 and increment the second column (Figure 1-9). 

Observe that the binary values in Figure 1-9 have been split into 
two 4-bit groups. This form of representation is not typical, but it is used 
here to emphasize the fact that each hexadecimal digit maps directly onto 
four bits. 

Also note that binary and hexadecimal values are often prefixed 
(padded) with leading zeros. This practice is used to illustrate the num¬ 
ber of digits that will be used to represent these values inside the com¬ 
puter. For our purposes here, we’re assuming a data bus that’s eight bits 
wide, so the values shown in Figure 1-9 have been padded to reflect this 
width. 

Combining digits and column weights in hexadecimal 

As with any place-value system, each column in a hexadecimal number 
has a weight associated with it; the weights are derived from the base. In 
this case we’re dealing with a base of sixteen, so the column weights will 
be 16° = 1, 16^ = 16, 16^ = 256, 16^ = 4,096, and so forth (Figure 1-10). 

As we discussed earlier in this chapter, it’s common practice to use 
subscripts to indicate whichever base is in use at the time. For example, 
4F0 Ai 6 = 20,234io, which means dFOAnexadecimai = 20,234Dedinai- As we 


Decimal 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

Hexadecimal 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

A 

B 

C 

D 

E 

F 


Figure 1-8. The sixteen hexadecimal digits. 
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Value 

Decimal 

Binary 

Hexadecimal 

zero 

0 

00 00 

00 00 

00 

one 

1 

00 00 

00 0 1 

01 

two 

2 

0000 

00 10 

02 

three 

3 

0000 

00 11 

03 

four 

4 

00 00 

01 00 

04 

five 

5 

0000 

0101 

05 

six 

6 

0000 

0110 

06 

seven 

7 

00 00 

0111 

07 

eight 

8 

00 00 

10 00 

08 

nine 

9 

0000 

1001 

09 

ten 

1 0 

00 00 

10 10 

OA 

eleven 

1 1 

00 00 

10 11 

OB 

twelve 

1 2 

0000 

1100 

OC 

thirteen 

1 3 

00 00 

110 1 

OD 

fourteen 

1 4 

00 00 

1110 

OE 

fifteen 

1 5 

0000 

1111 

OF 

sixteen 

1 6 

000 1 

0000 

1 0 

seventeen 

1 7 

00 0 1 

00 0 1 

1 1 

eighteen 

1 8 

000 1 

00 10 

1 2 


Figure 1-9. Counting in hexadecimal. 


^ Four thousand and ninty-sixes column —. 

r- Two hundred and fifty-sixes column-s 

, - Sixteens column- n 

, - Ones column-% 

4 F 0 Ai 6 ^®^umber' = ^ + (0 x 16^) + (A x 16°) 

= (4 x4,096)+ (Fx 256)+ (0x 16) + (Axl) 

= 16,384 + 3,840 + 0 + 10 


Decimal 

equivalent 


20,23410 


Figure 1-10. Combining digits and column weights in hexadecimal. 
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also noted, another common alternative is to prefix such numbers with a 
character to indicate the base. For example, $4F0A, where the $ indicates 
a hexadecimal value. (By now it may not surprise you to learn that, once 
again, there are a variety of such conventions.) As usual, any number 
without a subscript or a prefix character is generally assumed to repre¬ 
sent a decimal value unless otherwise indicated. 

Mapping between hexadecimal and binary 

Mapping between hexadecimal and binary is extremely simple. For ex¬ 
ample, in order to convert the hexadecimal value $4F0A into binary, all 
we have to do is to replace each hexadecimal digit with its 4-bit binary 
equivalent. That is, 

$4^ %0100, $F^ $0 ^ %0000, and $A^ %1010 

So $4F0A in hexadecimal equates to %0100111100001010 in binary. 

Similarly, it’s easy to convert a binary number such as 
%1100011010110010 into its hexadecimal equivalent. All we have to do 
is to split the binary value into 4-bit nybbles and to map each nybble 
onto its corresponding hexadecimal digit. That is, 

%1100 ^ $C, %0110 ^ $6, %1011 ^ $B, and %0010 ^ $2 

So%ll 00011010110010 in binary equates to $C6B2 in hexadecimal. 

Review 

This chapter introduced the concepts of place-value number systems, the 
binary and hexadecimal number systems, using powers or exponents, 
and using wires to represent numbers. Now, just to make sure that we 
fully understand these concepts, let’s answer the following questions 
and/or perform the following tasks: 

1) What is the decimal equivalent of the Roman numeral 
MMMDCCLXXVIII? 

2) In the case of a value such as 10^, what terms are used to refer to the 
10 and the 3, respectively? 

3) What term is used to refer to a binary digit, and to what do the 
terms nybble and byte refer? 
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4) What are two different ways to indicate that the value 10100101 is a 
binary number? 

5) What are two different ways to indicate that the value 10 is a hexa¬ 
decimal number? 

6) Convert the decimal value 125io into an 8-bit unsigned binary 
equivalent. 

7) Convert the binary value IOIOOIOI 2 into its hexadecimal equivalent. 

8) Convert the hexadecimal value $E6 into its binary equivalent. 

9) How many digits would there be in a quinary (base-5) place-value 
number system (list these digits); what would be the first five col¬ 
umn weights in such a system; and how would one count in such a 
system? 

10) Assuming positive numbers starting at 0, what range of decimal 
numbers could be represented using the different binary patterns 
that could be accommodated by a set of seven wires? How about 
nine wires? 

Cast your mind back to our discussions on counting with 
wires and Figure 1-7. There are two key problems associated with this 
form of binary representation. Can you spot what they are? 
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CHAPTER 

2 COMPUTERS AND 
CALCULATORS 


It is unworthy of excellent men to lose hours, 
like slaves, in the labors of calculation. 

Gottfried Wilhelm Leibnitz (1646-1716) 

Computers make it easier to do a lot of things, 
but most of the things they make it easier to 
do don't need to be done. 

Andy Rooney (1919-) 
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In this chapter we will learn about: 

• The brain of a computer 

• Memory devices 

• Input and output ports 

• The control, data, and address busses 

• Using a computer to make a calculator 

• Our DIY Calculator 
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Rampaging Around a Computer 

In its broadest sense, a computer is a device that can accept information 
from the outside world, process that information using logical and/or 
mathematical operations, make decisions based on the results of this 
processing, and ultimately return the processed information to the out¬ 
side world in its new form. 

The main elements forming a computer system are its central pro¬ 
cessing unit {CPU )—the memory devices (ROM and RAM) that are used 
to store programs (sequences of instructions) and data—and the 
input/output (I/O) ports that are used to communicate with the outside 
world (Figure 2-1). 

The “brain” of the computer is its CPU, which is where all of the 
number crunching and decision making is performed. Two of the 
CPU’s input pins are driven by externally generated signals called clock 
and reset. The clock signal switches back and forth between two voltage 
levels millions of times a second (or billions of times a second in the 
case of today’s computers). In much the same way that the measured 
beat of a drum can be used to keep a band marching in step, the 
clock signal is used to synchronize the internal and external actions of 
the CPU. 



Figure 2-1. The main components forming a general-purpose digital computer. 
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Sometimes, things may end up “pear-shaped” (an English expres¬ 
sion for something that has taken an unfortunate turn of events, such as 
a badly written program becoming locked up in an endless loop). In this 
case, the reset signal can be used to force the CPU into a known, well-be¬ 
haved state. (This signal is automatically activated when power is first 
applied to the system, and the resulting power-on reset serves to initialize 
the CPU.) 


Prior to the availability of ROM devices, computer users had to manually install the initialization in- 
structions each time the computer was powered on. This was usually accomplished by setting a bank of switch¬ 
es for each instruction and then pushing a button to input that instruction. This process, referred to as “boot¬ 
ing up the computer,” could be long and tedious. 

“Bootstraps” are small loops of leather sewn into the tops of high boots as an aid to pulling them on. Since the 
18th century, the phrase “pulling oneself up by one’s own bootstraps” has meant “to succeed by one’s own ef¬ 
forts.” Although “bootstrap” has been used in computing circles since the 1950s, the now-common shortened 
form “boot” only became popular with the “personal computer explosion” of the 1980s. 


Memory Devices and I/O Ports 

With regard to the other components forming a computer system, the 
ones in which we are interested here are the memory devices (each of 
which may contain thousands or millions of pieces of data) and the in¬ 
put and output ports. (In this context, the term “data” may be used to 
encompass the raw data upon which programs operate along with the se¬ 
quences of instructions forming the programs themselves.) 

As their name might suggest, the data contained in read only memo¬ 
ries (ROMs) is hard-coded during their construction. The CPU can read 
(extract) data from ROM devices, but it cannot write (insert) new data 
into them. Thus, ROMs may be used to store such things as the low-level 
initialization and control routines that are required when the computer 
is first powered up. 

By comparison, data can be read out of random access memories 
(RAMs) and new data can be written back into them (the act of reading 
data from a RAM does not affect the master copy of the data stored in¬ 
side the device). When power is first applied to the system, the RAMs 
end up containing random values; this means that any meaningful data 
stored inside a RAM must be written into it by the CPU (or via some 
other mechanism) after the system has powered up. RAMs can be used to 
store programs, data, and intermediate results. 
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Last but not least, the computer uses its input and output ports to 
communicate with the outside world. (Figure 2-1 shows only individual 
input and output ports, but a computer can effectively have as many of 
each type as its designers wish to use.) 


In addition to being somewhat esoteric, early attempts to create computer memories were typically 
sequential in nature. By this we mean that it was only possible to retrieve data in the order in which it had been 
stored (consider a magnetic tape, for example). 

Thus, when it was invented, the term random access memory (RAM) was coined to emphasize the fact that this 
new type of memory allowed data to be directly read from or written to any location in the device. 

Some of us would prefer to use the more meaningful appellation read-write memory (i?WM), but there is little 
chance of this nomenclature becoming widely adopted. 


The Control, Data, and Address Busses 

As we previously noted, the term bus is used to refer to a group of signals 
that carry similar information and perform a common function. A com¬ 
puter actually makes use of three buses called the control bus, address bus, 
and data bus. The CPU uses its address bus to “point” to other compo¬ 
nents in the system, it uses the control bus to indicate whether it wishes 
to “talk” (output/write/transmit data) or “listen” (input/read/receive 
data), and it uses the data bus to convey information back and forth be¬ 
tween itself and the other components. (To be honest, the clock and reset 
signals are also considered to be part of the control bus, but these signals 
are often treated separately as is illustrated in our diagrams.) 

The data bus 

For the purposes of these discussions, we’U assume that we’re working 
with a simple computer that has an 8-bit data bus. Note that the illustra¬ 
tion shown in Figure 2-1 is rather abstract and makes the busses look like 
solid entities. In reality, they are formed from groups of wires; for exam¬ 
ple, let’s take a closer look at the data bus (Figure 2-2). 

The address bus 

Now try to visualize a series of thousands upon thousands of boxes 
standing side-by-side and stretching away into the dim and distant be¬ 
yond. Each box is numbered sequentially, commencing with zero 
(Figure 2-3). 
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To/from RAM To/from Rest 




(a) Abstract view 


(b) Less abstract view 


Figure 2-2. The data bus. 


Let’s imagine that some of these boxes have pieces of transparent 
plastic sealing their ends, whereas the others are open to the elements. 
Let’s further suppose that each of the sealed boxes contains a slip of pa¬ 
per with a number written on it. We can read the numbers (data) on the 
slips inside these boxes but we can’t alter them in any way. This is similar 
to the way in which our ROM devices function. 

In the case of an open box, we can write a number on a new slip of 
paper and insert it into that box. If an open box already contains a slip of 
paper, we might simply read the number on the slip but leave the slip 
where it is, we might copy the slip and place the copy in another box, or 
we might erase the number on the slip and write a new number in its 
place. This is similar to the way in which our RAM devices operate. 

Strange as it may seem, this is the way that the CPU views its 
world—as a series of boxes that can be used to store instructions and 
data (although we prefer to use the term memory locations rather than 
“boxes”). Each location in the memory has a unique identification num- 



Sealed boxes (ROM) Open boxes (RAM) 


Figure 2-3. A series of boxes. 
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ber, referred to as its address, and the CPU uses its address bus to “point” 
to any memory location in which it is currently interested (Figure 2-4). 

Each location in the memory is referred to as a word, and each 
word has the same width as the data bus. Thus, as our CPU’s data bus is 
8 bits wide, each word in the memory must also be 8 bits wide. These bits 
are numbered from 0 to 7, as shown in Figure 2-4 (the reason for this 
numbering scheme is revealed in Chapter 4). Each bit in a memory word 
can be used to store a 0 or a 1, and all of the bits forming a word are typi¬ 
cally written to or read from simultaneously (the Os and Is shown in the 
memory word at address $000A in Figure 2-4 have no meaning beyond 
providing some example values). 

The totality of memory locations that can be addressed by the 
computer are referred to as its address space. In the case of our CPU, 
we’re going to assume that the address bus is 16 bits (two bytes) wide. 
This means that our address bus can carry 2^® unique combinations of 
Os and Is, which can therefore be used to point to 65,536 different 
memory locations numbered from 0 to 65,535. For a variety of reasons, 
however, it is not convenient to refer to the addresses of memory loca¬ 
tions using a decimal notation. Thus, rather than referring to a location 
such as 48,259 using its decimal value (or worse, its binary equivalent 
of % 1011110010000011), it is common practice to refer to addresses 
using a hexadecimal notation such as $BC83 (remember that we’re us¬ 
ing the % and $ characters to indicate binary and hexadecimal values, 
respectively). 


- Control Bus 

Data Bus 


'$' characters indicate 
hexadecimal numbers. 


Address Memory 

$0000 



Figure 2-4. The address bus. 




































CAREENING AROUND A CALCULATOR 


29 


Actually, we should note that the computer architecture we’re de¬ 
scribing here reflects a very simple system that one might And in a low- 
end application like a pocket calculator. This type of architecture was also 
common in personal computers circa 1975. The busses and bus protocols 
used in modern computers like PCs are much more sophisticated; but, as 
was noted in Chapter 0, once you fully comprehend how a simple com¬ 
puter functions, you can easily extrapolate to more complex machines. 


Careening Around a Calculator 

Once we’ve conceived the idea of a general-purpose computer, the next 
step is to think of something to do with it. In fact, there are millions of 
tasks to which computers can be assigned, but the application we’re in¬ 
terested in here is that of a simple calculator. So what does it take to co¬ 
erce a computer to adopt the role of a calculator? Well, one thing we re¬ 
quire is some form of user interface, which will allow us to present data 
to, and view results from, the computer (Figure 2-5). 

The calculator’s user interface primarily consists of buttons and 
some type of display. Each button has a unique binary code associated 
with it, and this code will be presented to the computer’s input port 
whenever that button is pressed. Meanwhile, one or more of the com- 



Figure 2-5. A calculator requires some form of user interface. 
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puter’s output ports can be used to drive the display portion(s) of the 
interface. 

So this interface is really a “dumb device,” because all of the actual 
number crunching is performed by the general-purpose computer. How¬ 
ever, in order for the computer to perform its cunning machinations, it 
requires a program, and creating this program requires us to decide on 
the ways in which we wish to represent and manipulate numbers. Ulti¬ 
mately, the purpose of this book is to introduce methods of representing 
numerical data inside a computer and techniques for manipulating this 
data so as to perform common arithmetic operations. 


The DIY Calculator 


As we mentioned in Chapter 0, one of the best ways to learn something 
and remember it afterward is by means of hands-on (“fumble and stum¬ 
ble”) experience, which you are about to gain in huge dollops. As a key 
element in this “ordeal by fire,” you are going to create a program to im¬ 
plement a simple calculator by performing a series of interactive labora¬ 
tories featuring the internationally acclaimed DIY Calculator. 

What is a DIY Calculator and where might one be found? As fate 
would have it, this little rapscallion, which was conceived and designed 
by the authors, comprises a calculator front panel (the user interface dis¬ 
cussed in the previous section) connected to a simple general-purpose 
computer with a 16-bit address bus, an 8-bit data bus, some RAM and 
ROM, and a number of input and output ports. But the really cunning 
thing about the DIY Calculator is that, as opposed to being constructed 
from physical components, it has been implemented as a virtual machine 
(a simulator) that runs on your PC and is delivered on the CD-ROM ac¬ 
companying this book. 

If you haven’t already done so, install your DIY Calculator now (see 
Appendix A). Once you’ve performed this installation, use the Start > 
Programs > DIY Calculator > DIY Calculator command (or double¬ 
click the DIY Calculator icon on your desktop) to invoke the little scamp 
(Figure 2-6). 

In the middle of the main DIY Calculator window is the calculator 
front panel (sometimes we’ll simply refer to this as the “calculator” or 
“front panel” for short). This is the graphical interface that can be used to 
feed data to, display results from, and control our calculator (Figure 2-7). 
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Figure 2-6. The main DIY Calculator window. 
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Figure 2-7. The calculator front panel. 
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As you can see, the calculator front panel is festooned with but¬ 
tons with which you are soon to become intimately acquainted. 

Observe that some of these buttons have been left blank for you to as¬ 
sign your own operations. Also note that you can reconfigure the front 
panel to modify the legends on the buttons, change the colors of the 
legends, and so forth. These aspects of the front panel are discussed in 
Chapter 6. 

At the bottom left-hand side of the front panel are a group of four 
special control buttons: On/Off, Reset, Step, and Run. Just to get a feel 
for what’s going on, click the On/Off button to power-up the calculator 
(that is, the front panel and the computer, our simulator, “behind” the 
front panel). Note that the main display area fills up with characters, 
indicating that it’s in an uninitialized state. Similarly, the six little lights 
next to the Bin, Dec, and Hex (and related) buttons, located just beneath 
the main display area, all glow red to indicate that they too are in an 
uninitialized state. 

Try clicking the calculator’s 0 through 9 button, and note that 
nothing happens whatsoever. This is because, thus far, you haven’t 
loaded a program into the calculator’s memory. 

Next, use the main DIY Calculator window’s Memory > Load 
RAM pull-down menu to invoke a dialog offering a list of the programs 
that are currently available. By default, this dialog should be looking in 
the C:\DIY CalculatoAWork folder; if not, set the context to this folder. 
Select (click on) the test.ram file you’ll find in the Work folder and then 
click the Load button to load the contents of this file into the calculator’s 
memory. 

Now click the front panel’s Run button to execute the program 
and note that the main display is cleared and the six little lights go out. 
Next, try clicking the 0 through 9 buttons again and observe what 
happens. 

Note that these are the only buttons that do anything; the other 
function buttons have no effect (don’t play with the On/Off, Reset, Step, 
or Run control buttons until instructed to do so). The reason for this is 
quite simple. After clearing the display, all this particular program does is 
to loop around waiting for you to click a button. If this button corre¬ 
sponds to 0 through 9, the program copies that value back to the display; 
otherwise, it ignores you and returns to looping around waiting for you 
to click another button. 
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Interactive Laboratories 


When you’ve finished playing, click the On/Off button to power-down 
the calculator. Now you’re really ready to rock and roll, so take a deep 
breath and perform the following interactive laboratories that you’ll find 
toward the back of this book: 


lab 2a: Creating a Simple Program 

lab 2b Constant Labels and .EQU Statements 

lab 2C: Driving the Front Panel’s Main Display 

lab 2d: Reading from the Front Panel’s Keypad 

lab 26: Writing to the Front Panel’s Six LEDs 

lab2f: Using the Memory Walker and Other Diagnostic Displays 

Review 

This chapter introduced the main elements of a computer system and 
described how a computer could be used in the role of a calculator. 

1) What does the abbreviation CPU stand for and what is its role in a 
computer system? 

2) What do the abbreviations ROM and RAM stand for? 

3) Summarize the key features of ROM and RAM devices. 

4) Name the three busses used by a computer and describe their 
various roles. 

5) Summarize the actions of the clock and reset control signals. 

6) What is the purpose of the power-on reset circuit? 

7) What elements does the computer use to “talk” to the outside 
world? 

8) To what do the terms word and address space refer? 

9) What key services are provided by a calculator’s front panel? 

10) What are the names of the CPU’s status flags?^ 

'You will need to have performed the interactive laboratories associated with this chapter 
in order to be able to answer this question. 
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Logical Instructions (AND, OR, 
and XOR) 

As we’re sure you noticed, this chapter is entitled “Subroutines and 
Other Stuff.” Well, by some strange quirk of fate, we’re actually going to 
start with the “other stuff.” 

Primitive logic gates 

In Chapter 1, we noted that computers are formed from large numbers 
of primitive logical elements called logic gates. We also noted that it’s rel¬ 
atively easy for electronics engineers to create logic gates that can detect, 
process, and generate two distinct voltage levels, and that these two levels 
can be used to represent binary 0 and 1, respectively. 

In addition to considering 0 and I as representing numerical infor¬ 
mation in the form of binary digits, we sometimes prefer to think of 
them in terms of the logical values False and True, respectively. As an ex¬ 
ample of this way of looking at things, consider three different types of 
logic gates called AND, OR, and XOR (Figure 3-1). 

Each symbol has an associated truth table, which provides a useful 
way of representing the different possible input combinations and their 
corresponding output values. In the case of the AND gate, the output Y 
is only True (logic 1) if both inputs A and B are True; for any other com¬ 
bination of inputs, the output is False (logic 0). By comparison, in the 
case of the OR gate, the output Y is True if either input A or B is True. In 
fact, this form of OR should more properly be called an “Inclusive OR,” 
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Figure 3-1. AND, OR, and XOR logic gates. 
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because the cases where the output is True include the one where both of 
the inputs are True. Contrast this with the XOR (“Exclusive OR”), where 
the True output cases exclude the case where both inputs are True. 

Logical instructions 

The point behind all of this is that, in addition to performing arithmetic 
operations such as incrementing (adding 1 to) the accumulator using an 
INCA^ instruction, or adding two numbers together using an ADD^ in¬ 
struction, we often desire to perform logical operations on the contents 
of the accumulator. Thus, our virtual computer is equipped with the log¬ 
ical instructions AND, OR, and XOR, which cause a byte of data stored 
in the memory to be AND-ed, OR-ed, or XOR-ed with the current con¬ 
tents of the accumulator, respectively. The results from these operations 
are stored in the accumulator, thereby overwriting its original contents 
(the contents of the memory remain undisturbed). 

In order to illustrate the way in which these instructions perform 
their magic, let’s assume that the accumulator originally contains 
0000111 12 and that we wish to either AND, OR, or XOR this value with a 
memory location containing OIOIOIOI 2 (Figure 3-2). 

The key point to note about these logical instructions is that they 
operate in a bit-wise fashion (that is, on a bit-by-bit basis). In the case of 
the AND, for example, bit 0 in the memory is AND-ed with bit 0 in the 
accumulator and the result is stored in bit 0 in the accumulator, bit 1 in 
the memory is AND-ed with bit 1 in the accumulator and the result is 
stored in bit 1 in the accumulator, and so forth. 

As we shall come to discover, these logical operators can be ex¬ 
tremely useful for a wide variety of tasks. For example, suppose the accu¬ 
mulator contains a value of 1110001 12 and we wish to set bit 3 (the mid¬ 
dle 0 in the group of three Os) to a 1. We can achieve this by OR-ing the 
accumulator with OOOOIOOO 2 , resulting in 11101011 2 . (Remember that 
the eight bits forming the accumulator are numbered left to right from 
0 to 7, as shown in Figure 3-2.) 

Alternatively, consider the case where the accumulator contains a 
value of 1110001 12 and we wish to clear bit 6 (the middle 1 in the group 
of three Is) to a 0. We can achieve this by AND-ing the accumulator with 
IOIIIIII 2 , resulting in 1010001 12 . 

'The INCA instruction was introduced in Lab 2c. 

^The ADD instruction is presented in Chapter 4. 
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Figure 3-2. AND, OR, and XOR instructions. 


Another useful logical operation is the NOT. Sad to relate, our vir¬ 
tual computer does not actually support a NOT instruction, although, if it 
did, this instruction would invert all of the bits in the accumulator 
(swapping the Os for Is, and vice versa). But turn that frown upside 
down into a smile, because we can achieve the same effect by XOR-ing 
the contents of the accumulator with a value comprising all Is. For ex¬ 
ample, if the accumulator originally contains a value of 001IOIOI 2 , then 
XOR-ing it with IIIIIIII 2 will return a result of IIOOIOIO 2 . 


Shift Instructions (SHL and SHR) 

Some computers offer two different “flavors” of shift instructions known 
as arithmetic shifts and logical shifts. In such a case, each of these flavors 
would have “shift left” and “shift right” variants, which means we would 
end up with four instructions as follows: 


Mnemonic Function 

ASHL Arithmetic shift left 

ASHR Arithmetic shift right 

LSHL Logical shift left 

Logical shift right 


Note 

Called SHL in our virtual computer 
Called SHR in our virtual computer 
Not supported hy our virtual computer 
Not supported by our virtual computer 


LSHR 









































































































SHIFT INSTRUCTIONS (SHL ND SHR) 


39 


Arithmetic shifts 

The easiest approach to visualize the way in which these work, and to 
compare the commonalities and differences between them, is by means 
of diagrams. Let’s begin by considering the arithmetic shifts that our vir¬ 
tual computer does support (Figure 3-3). 

Note that the question mark “?” shown as the original value in 
the C (carry) status flag indicates that, for the purposes of this exam¬ 
ple, we don’t know (or care) whether this flag starts off containing a 0 
or a 1. (The status flags were introduced in Lab 2c.) 

In the case of the arithmetic shift left (for which our mnemonic is 
SHL), a logic 0 is shifted into the least-significant (right-hand) bit, all of 
the other bits shift one place to the left, and when the original value in 
the most-significant (left-hand) bit “falls off the end” it is copied into the 
carry flag. By comparison, in the case of the arithmetic shift right (for 
which our mnemonic is SHR), the most-significant (left-hand) bit is 
copied back into itself At the same time, the most-significant bit, along 
with all of the other bits, shifts one place to the right, and when the origi¬ 
nal value in the least-significant (right-hand) bit “falls off the end” it is 
copied into the carry flag. 
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Figure 3-3. Arithmetic shifts supported by our virtual computer. 








































































40 


SUBROUTINES AND OTHER STUFF 


Logical shifts 

Now let’s take a look at the logical shifts that our virtual computer does 
not support (Figure 3-4). 

As we can see, the logical shift left instruction functions in an iden¬ 
tical manner to its arithmetic counterpart. In fact, even in a system that 
does purport to offer both flavors, this would, in reality, be an illusion. In 
such a case, the assembler would accept both ASHL and LSHL mnemon¬ 
ics, but each of these would map onto the same opcode as seen by the 
CPU. So why would an assembler offer both mnemonics in the first 
place? For aesthetic reasons mostly (in order to provide one-for-one 
matches with the different flavors of shift right), but also, to a lesser ex¬ 
tent, because it helps to signify what the programmer had in mind when 
creating the code. 

The real difference is between the arithmetic and logical versions 
of a shift right. Remember that the arithmetic version copies the most- 
significant bit in the accumulator back on itself By comparison, in the 
case of a logical shift right instruction, a logic 0 is shifted into the 
most-significant bit. 
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Figure 3-4. Logical shifts not supported by our virtual computer. 
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Coercing the results from arithmetic shift rights into 
their logical counterparts 

The reasons why we are interested in arithmetic versus logical shift right 
instructions are presented in more detail in Chapter 4. For our purposes 
here, we need only reiterate that our virtual computer supports only 
arithmetic shifts, which we decided to call SHL (“shift left”) and SHR 
(“shift right”) for simplicity. 

But will the lack of logical shift instructions be detrimental to our 
ability to write useful programs and our general standing in the commu¬ 
nity? Fear not, because as we already noted, arithmetic and logical shift 
lefts do the same thing anyway. Meanwhile, there’s a simple trick we can 
play to coerce the results from arithmetic shift rights into their logical 
shift right equivalents. Once we’ve performed an arithmetic shift right, 
we can force it into its logical counterpart by means of an AND instruc¬ 
tion as discussed earlier in this chapter; for example: 

LDA %11001110 # Load accumulator some value 

SHR # Perform an arithmetic shift right 

AND %01111111 # Coerce result into logical version 

First, we load the accumulator with the same “seed value” (1100111 02 ) 
we used in the examples shown in Figures 3-3(b) and 3-4(b). Next, we 
use our SHR instruction to perform an arithmetic shift right, which re¬ 
turns the same result we saw in Figure 3-3(b) (IIIOOIII 2 ). Finally, we 
use our and instruction to mask out the most-significant bit and clear it 
to a 0, which leaves us with the same logical shift right result we saw in 
Figure 3-4(b) (OIIOOIII 2 ). (A good example of an actually usage of this 
technique is to be found in Lab 3a.) 


Rotate Instructions (ROLC and RORC) 

Our virtual calculator supports two rotate instructions: ROLC (“rotate 
left through the carry flag”) and RORC (“rotate right through the carry 
flag”), as illustrated in Figure 3-5. 

These are very similar to the logical shift instructions we discussed 
in the previous section. The big difference is that, instead of shifting a 
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Figure 3-5. The rotate through carry instructions supported by our virtual computer. 


logic “0” into the “input end” of the accumulator, we actually feed in the 
original value from the carry flag. Once again, the question mark “?” 
shown as the original value in the carry flag indicates that, for the pur¬ 
poses of this example, we don’t know whether this flag starts off contain¬ 
ing a 0 or a 1. The point is that, whatever this value is, it ends up in the 
least-significant bit of the accumulator following the ROLC instruction, 
or the most-significant bit following the RORC instruction. 

Rotates that bypass the carry bit 

Some computers also support rol (“rotate left”) and ROR (“rotate 
right”) instructions, which we might class as “rotate bypassing carry.” 

In this case, whichever bit is conceptually “falling off the end” of the 
accumulator is fed directly back into the other end of accumulator 
(Figure 3-6). 

Coercing rotates through the carry bit into their 
bypass counterparts 

All four rotate instructions (ROLC, RORC, ROL, and ROR) are useful de¬ 
pending on the occasion, so why did we decide that our virtual computer 
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C (carry) flag C (carry) flag 

Figure 3-6. The rotate bypassing carry instructions not supported by 
our virtual computer. 


would support only the rotate through carry versions? The answer is that 
we wanted to keep our computer’s instruction set as simple and mini¬ 
malist as possible; also, it’s easier to convert the results from a rotate 
through carry instruction into its rotate bypassing carry counterpart than 
to do things the other way around. For example, consider the following 
technique for coercing the result from a ROLC into the result from a ROL: 



LDA 

ROLC 

%11001110 

# 

# 

Load accumulator with some value 

Perform a rotate-left-through-carry 


JC 

[FORCEl] 

# 

If carry = 1, 

jump to label FORCEl 

FORCE0: 

AND 

%11111110 

# 

... otherwise 

clear LS bit to 0 


JMP 

[CONTINUE] 

# 

Unconditional 

jump to label CONTINUE 

FORCE1: 

OR 

%00000001 

# 

Set LS bit to 

1 

CONTINUE: 



# 

Continue with 

rest of program 


The way this works is that, following the ROLC instruction, we know that 
whatever value is in the carry flag is the value we actually want to see in 
the least-significant bit (LSB) of the accumulator. If the value in the carry 
flag is 0, the JC instruction will fail, and the AND %11111110 instruc¬ 
tion will be used to clear the LSB to 0. Alternatively, if the value in the 
carry flag is 1, the JC instruction will pass, and the OR % 0 0 0 0 0 0 01 in¬ 
struction will be used to set the LSB to 1. 

Suppose that we had opted to implement the ROL and ROR in¬ 
structions in our virtual computer and not to implement the ROLC and 
RORC versions. In this case, how would you coerce the result from a ROL 
into the result from a ROLC (or the result from a ROR into the result from 
a RORC)? 
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This would be a really good time to perform Lab 3a, which provides some “hands-on” use of the logi¬ 
cal and shift instructions. 


The Program Counter (PC) 

The CPU contains a number of registers that it uses to point to in¬ 
structions and data in the memory. First and foremost is the pro¬ 
gram counter (PC), which keeps track of where the CPU is in a 
program. 

The program counter is a 16-bit register whose bits are numbered 
from 0 to 15, but it may help us to visualize this register as being formed 
from a most-significant byte (MSB) and a least-significant byte {LSBy 
(Figure 3-7). 

Most of the time, the program counter is used to drive the CPU’s 
address bus; that is, the contents of the program counter are presented to 
the outside world via the address bus. As the program counter and ad¬ 
dress bus are both 16 bits (two bytes) wide, they can be used to point to 
2^® = 65,536 unique memory locations numbered from $0000 to $FFFF 
(or 0 to 65,535 in decimal). 

It’s interesting to note that there really isn’t any way for us to 
control the program counter per se. When the CPU is first powered 
up, the program counter potentially initializes with an unknown value. 
What saves it from this fate is the system’s power-on reset circuit, 
which applies a pulse to the reset input driving the CPU. This initializes 
a lot of things, including loading the program counter with some 
known good value; for example, $0000, which is the first instruction in 
the virtual monitor program stored in our virtual computer’s ROM. 
After this point, the program counter follows the dictates of the pro¬ 
gram itself. 



^Yes, we know that the abbreviations for most-significant bit {MSB) and most-significant 
byte (MSB) are the same, and similarly for least-significant bit (LSB) and least-significant 
byte (LSB). This is how engineers get their fun! 
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Figure 3-7. The 16-bit program counter drives the CPU’s address bus. 


The Index Register (X) 

Another CPU register that often proves to be very useful is the index reg¬ 
ister (X) (Figure 3-8). Like the program counter, the index register is also 
a 16-bit entity whose bits are numbered from 0 to 15 but, once again, it 
may help us to visualize this register as being formed from a most-signif¬ 
icant byte (MSB) and a least-significant byte (LSB). 



Figure 3-8. The 16-bit index register can be used to modify the value on the 
address bus. 
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Of particular interest is the fact that the index register can be used 
to modify the value being driven out on the address bus. For example, 
consider an LDA instruction using the absolute addressing mode, such as 
LDA [$5000]. This loads the accumulator with the byte of data stored in 
the memory location whose address is $5000. 

By comparison, consider an LDA using the indexed addressing 
mode, such as lda [ $ 5 0 0 0 , x ]. In this case, the accumulator will be 
loaded with the byte of data stored in the memory location whose address 
is calculated by adding $5000 to the contents of the index register (X). 

When the CPU is first powered up, the index register initializes 
with an unknown value. Thus, if we want to use this register, we first 
have to load it with something useful. Purely for the sake of an example, 
let’s assume that we want to load it with a value of $0006 (that’s just 6 in 
decimal). In this case, we’d use a bldx (“big load index register”) in¬ 
struction: BLDX $ 0006. The reason this is referred to as a “big load” is 
that the index register is 16 bits wide, as compared to the accumulator, 
which is only 8 bits wide. 

Once we’ve loaded the index register, we can modify its contents by 
means of the INCX (“increment index register”) and DECX (“decrement 
index register”) instructions, which add or subtract 1 from the contents 
of the register, respectively. 

If we wish, we can also use a BSTX (“big store index register”) in¬ 
struction, which copies the current contents of the index register to a 
specified location (2 bytes long) in the main memory. 


This would be a jolly good time to perform Lab 3c, in which different ways of using the index register 
are presented and discussed. 


The Stack and Stack Pointer (SP) 

Most of us have been to a cafeteria in which a pile of serving plates is 
stacked on top of a spring-like mechanism. Now let’s suppose that we are in 
a warehouse and that there is something similar in the middle of the floor, 
involving a flat metal plate mounted on top of a big spring (Figure 3-9). 

Initially, the mechanism is empty [Figure 3-9(a)]. Now suppose 
someone hands you a box with a big number “1” painted on its side. Af¬ 
ter standing around for a few moments looking rather foolish, you de- 
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(a) Empty (b) First “box” (c) Second “box” (d) Third “box” 

Figure 3-9. A spring-like mechanism in the middle of the floor. 


cide to place the box on the plate [Figure 3-9(b)]. A little later, someone 
else thrusts another package into your hands; this one has the number 
“2” painted on its side and you decide to put it on top of the first box 
[Figure 3-9(c)]. StiU later, you are presented with a third box carrying the 
number “3” and you set this on top of the pile [Figure 3-9(d)]. 

Time passes. You hang around twiddling your thumbs until some¬ 
one new rushes in and requests that you give them a package. Which one 
are you going to select? The obvious choice is the parcel on the top of the 
pile, so this is the one you retrieve and hand over. In computing terms, 
this form of storage and retrieval would be classed as a last in, first out 
(LIFO) process. 

Introducing the stack and stack pointer 

The point of these ramblings is that a CPU can be persuaded to make use 
of a concept known as the stack, which, if we really stretch our imagina¬ 
tions, we can visualize as working something like the spring-like mecha¬ 
nism discussed above. In order to point to the stack, the CPU employs 
yet another 16-bit register called the stack pointer (SP) (Figure 3-10). 

When our CPU is first powered up, the stack pointer initializes 
with random Os and Is, which means that we have to load it with some 
value if we wish to use it. For example, let’s assume that we want to load 
it with a value of $EFFF (we’ll return to this point in a moment). In this 
case, we’d use a bldsp (“big load stack pointer”) instruction of the form 
BLDSP $EFFF.^ (As usual, the reason this is referred to as a “big load” is 
that the stack pointer is 16 bits wide.) 

^There is also a corresponding bstsp (“big store stack pointer”) instruction, which 
copies the current contents of the stack pointer to a specified location (2 bytes long) in 
the main memory. 
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Figure 3-10. The 16-bit stack pointer is used to point to the stack. 


Pushing the accumulator onto the stack 

Let’s assume that we have indeed just loaded the stack pointer with a val¬ 
ue of $EFFF. We would say that the stack pointer is currently pointing to 
the top of the stack, which, at this particular moment in time, happens to 
be at memory location $FFFF [Figure 3-ll(a)]. 

Note that the $XX values shown in this figure indicate that these 
memory locations are uninitialized and currently contain random, un¬ 
known values. 

Now suppose that the accumulator contains a value (say, $01) 
that we wish to save for some future purpose. In this case, we could 
store it in some memory location using the absolute addressing mode; 
for example, STA [$5000] . As we know, this will copy the accumula¬ 
tor into memory location $5000. Alternatively, we could store the 
accumulator using the indexed addressing mode as discussed in the 
previous section, for example, STA [ $5 000 , X] , which will cause a 
copy of the accumulator to be stored in the memory location whose 
address is calculated by adding $5000 to the contents of the index reg¬ 
ister (X). 

But now we have a third possibility, which is to use a pusha (“push 
accumulator”) instruction. This causes a copy of the accumulator to be 
placed on the top of the stack at the location being referenced by the 
stack p ointer [ Figure 3 -11 (b)], and then the stack p ointer is auto - 
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Figure 3-11. Pushing the accumulator onto the stack. 


matically decremented to point to the next free location, the new top of 
the stack [Figure 3-11(c)]. 

Similarly, if we now loaded the accumulator with a new value (say 
$02) and performed another PUSHA instruction, this copy of the accumu¬ 
lator would be pushed onto the top of the stack [ Figure 11(d)], and the 
stack pointer would then be automatically decremented to point to the 
next free location [Figure 3-11(e)]. Thus, the reason we call this the “stack” 
is that the bytes of data are conceptually stacked on top of one another. 

Popping the accumulator back off the stack 

Purely for the purposes of these discussions, let’s assume that we origi¬ 
nally loaded our accumulator with a value of $01 as discussed above; 
then we cycled five times around a loop, pushing the accumulator onto 
the stack and then incrementing it each time, which would leave things 
as shown in Figure 3-12(a). 

Now suppose that we execute a popa (“pop accumulator”) instruc¬ 
tion. Remember that the stack pointer is currently pointing at the first 
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Figure 3-12. Popping the accumulator off the stack. 


free location on the top of the stack. Thus, the CPU first increments the 
stack pointer to point to the last piece of data we pushed onto the stack 
[Figure 3-12(b)], and then it copies (“pops”) that data off the stack into 
the accumulator [Figure 3-12(c)]. 

Note that the act of popping data off the stack doesn’t actually 
change the contents of that memory location ($EFFB in this example). 
However, as far as we are concerned, we cannot re-access that the data 
currently stored in that location by means of standard stack pointer- 
based operations. For example, if we were to execute another popa, the 
stack pointer would move further away from location $EFFB. Alterna¬ 
tively, if we were to execute another pusha, this would overwrite the 
contents of location $EFEB. 

Pushing and popping the status register 

In addition to the PUSHA (“push accumulator”) and POPA (“pop accu¬ 
mulator”) instructions, we also have their PUSHSR (“push status regis¬ 
ter”) and POPSR (“pop status register”) counterparts. This opens the 
door to a raft of possibilities. For example, we could use a pushsr fol¬ 
lowed by a POPA to first push a copy of the contents of the status register 
onto the stack and then pop a copy into the accumulator. We could then 
use the logical and, or, and XOR instructions to manipulate individual 
bits [for example, setting or clearing the Z (zero) flag]. Finally, we could 
use a PUSHA followed by a popsr to transfer this new value back into the 
status register. 
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Why use the stack at all? 

There are several reasons for using the stack (not the least being the use 
of subroutines, which are introduced in the next section). For example, if 
we are writing a program in which we know that we are never going to 
need to store more than ten bytes of data, then we might decide to sim¬ 
ply use something like a . BYTE * 10 directive to reserve these memory 
locations for future use. 

But what happens if we are performing some task such as reading 
(and storing) codes from buttons pushed on a keypad and we don’t 
know exactly how many values we are going to have to deal with. One 
solution would be to reserve the largest amount of memory possible, but 
we might need that memory for other tasks later on. The alternative 
would be to use the stack, which grows to whatever size is required and 
then shrinks again once its data is no longer required. 

Another point that is well worth considering is that PUSHA and 
POPA instructions take significantly fewer CPU clock cycles than do their 
STA and LDA counterparts, which means that using the stack can help 
speed up your programs (at least, this would be the case when working 
with a real, physical computer). 

Why does the stack pointer "appear" to work the 
wrong way round? 

One point you may have speculated about is “Why does a push instruc¬ 
tion cause the stack pointer to be decremented while a pop instruction 
causes it to be incremented?” After all, it would seem to be far more intu¬ 
itive to make it work the other way around. Well, the rationale behind 
this is really rather cunning. Let’s consider our virtual computer’s mem¬ 
ory map (Figure 3-13). 

The program counter (PC) starts off pointing to the first instruc¬ 
tion in our program, which is always located in the first location in the 
RAM at address $4000. As we add more instructions into our program, 
we can visualize it as “growing” toward the higher memory locations. 

As we know, we can initialize the stack pointer (SP) with any value. 
The reason we typically set it to the highest possible location in the RAM 
(address $EFFF in the case of our virtual computer) and the reason the 
stack “grows” in the opposite direction to the program is to save us a lot 
of pain. 
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pQ Program ''grow^' 
^ in this direction 


Stack ''growd' gp 

in this direction ^ 



11 


$0000 


$3FFF $4000 


$EFFF' 


$F000 


$F03F 


ROM RAM Input and output ports 

Figure 3-13. Our virtual computer’s memory map. 


The point is, when we start running a program, we often don’t 
know exactly how much data we are going to want to push onto the 
stack. However, if we commence the program at the lowest possible 
RAM address and we initialize the stack pointer to the highest possible 
address, then we can use all of the available memory to its maximum 
advantage. 

Of course, if we push too much data onto the stack, at some point 
the top of the stack will “collide” with the top of the program and start to 
overwrite it. This condition, which is known as a stack overflow, is gener¬ 
ally not considered to be a good thing to happen. Similarly, if we attempt 
to “pop” more data off the stack than we have “pushed” onto it, the re¬ 
sult will be a stack underflow (once again, we try not to let this occur). 


Now would be an appropriate time to perform Lab 3d, in which the stack and stack pointer are used 
to implement a new technique for displaying button values in reverse order. 


Subroutines 

As we discovered in the previous section and in Lab 3d, the stack and 
stack pointer, when used in conjunction with the PUSHA, POPA, PUSHSR, 
and POPSR instructions, are useful in their own right. But they really 
come into their own when combined with the concept of subroutines. 

A simple example 

Before we start, it’s important to note that the stack pointer must be ini¬ 
tialized in order for our subroutines to work (the reason for this will be- 
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come clear as we progress). As a very simple example, let’s assume that 
we have a program in which we have already used a bldsp (“big load 
stack pointer”) instruction to initialize the stack pointer to point to 
memory location $EFFF. Fet’s further assume that somewhere in the 
body of our program we wish to clear the calculator’s main display, 
which we can do by loading the accumulator with our special clear code 
and writing it to the display (these lines of code are highlighted in gray). 


BEFORE: 

NOP 


# 

A "no operation" instruction 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Write clear code to main display 

AFTER: 

NOP 


# 

Another "no operation" instruction 


Note that the NOP (“no operation”) instruction was introduced in 
Fab 3d. The two NOP instructions shown above are used only to provide 
points of reference for our future discussions. 

Now let’s suppose we wish to perform this “clearing the display” 
task multiple times throughout the course of our program. We could, of 
course, replicate the lda and STA instructions wherever we wished to 
perform this chore. Alternatively, we could create a subroutine called 
CLEAR (or any other label we choose to use), and then call this routine 
from the body of the program as required (the call to the subroutine and 
the lines of code comprising the routine are highlighted in gray). 


BEFORE: 

NOP 


# 

A "no operation" instruction 


JSR 

[CLEAR] 

# 

JSR = "Jump to subroutine" 

AFTER: 

NOP 


# 

# 

Another "no operation" instruction 

Body of the program 

########## 

Start 

of "clear 

display" subroutine 

CLEAR: 

LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] # 

Write clear code to main display 

RETURN: 

RTS 


# 

RTS = "return from subroutine" 


########## End of "clear display" subroutine 


The way in which this works is actually quite simple. When the CPU 
“sees” the JSR (“jump to subroutine”) instruction, it automatically 
pushes the address of the following instruction (the NOP associated with 
the AFTER label in this example) onto the top of the stack (this is known 
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as the “return address”); then it loads the program counter with the ad¬ 
dress of the first instruction in the subroutine (the LDA associated with 
the CLEAR label in this example). 

The CPU then continues to execute the subroutine until it reaches a 
RTS (“return from subroutine”) instruction, at which point it automati¬ 
cally pops the return address off the top of the stack and loads this value 
back into the program counter. 

A more detailed breakdown 

In order to truly wrap our brains around this, it would be useful to know 
where the various portions of our program end up in the calculator’s 
memory. Purely for the sake of discussion, let’s assume that the NOP as¬ 
sociated with the BEFORE label occurs at memory location $5000, the 
first instruction in our subroutine (the LDA associated with the CLEAR 
label) resides in memory location $6000, and, as was previously dis¬ 
cussed, the stack pointer has been initialized to point to memory location 
$EFFF (Figure 3-14). 

Now, keeping this illustration in mind, let’s consider how the sub¬ 
routine is executed in more detail. Fet’s assume that we’ve just executed 
the NOP associated with the label before, which means that the program 


Source code 


BEFORE: 

NOP 


JSR [CLEAR] 

AFTER: 

NOP 




CLEAR: 

LDA 

CLRCODE 


STA 

[MAINDISP] 

RETURN: 

RTS 





BEFORE: 


AFTER: 


CLEAR: 


RETURN: 


$5000 

$5001 

$5002 

$5003 

$5004 


$6000 

$6001 

$6002 

$6003 

$6004 

$6005 


$EFFD 

$EFFE 

$EFFF 


Memory 
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Figure 3-14. Visualizing the program in the computer’s memory. 
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counter (PC) is currently pointing to the JSR (“jump to subroutine”) in¬ 
struction at address $5001 [Figure 3-15(a)]. 

When the CPU executes the JSR instruction, it first pushes the 
return address (the address of the NOP at label after, which is $5004) 
onto the top of the stack, and then it loads the target subroutine ad¬ 
dress into the program counter. This leaves the stack pointer (SP) 
pointing to the first free location on top of the stack at address $EFFD 
and the program counter pointing at the first instruction in the 
subroutine, the lda associated with label clear at address $6000 
[Figure 3-15(b)]. 

Now let’s assume that the CPU has executed the instructions form¬ 
ing the subroutine and that the program counter is currently pointing 
to the RTS (“return from subroutine”) instruction at address $6005 
[Figure 3-15(c)]. 

When the CPU executes the RTS instruction, it pops the return 
address (the address of the NOP at label aeter, which is $5004) off the 
top of the stack and loads this address into the program counter. This 
leaves the stack pointer pointing at the old top of the stack at address 
$EFFF and the program counter pointing at the instruction following 
the JSR [Eigure 3-15(d)]. 
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Figure 3-15. The actions of the program counter (PC) and stack pointer (SP). 
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Multiple calls to the same subroutine 

There are a few additional points relating to subroutines that are worth 
noting before we actually start to play with them. First of all, a subrou¬ 
tine may be called multiple times from the main body of the program, 
for example: 

###### This is the main body of the program 


Inst" 

JSR [CLEAR] 

Inst" 


# Some instruction or other 

# Call CLEAR subroutine 

# Some instruction or other 


# More instructions 


Inst" 

JSR [CLEAR] 

Inst" 


# Some instruction or other 

# Call CLEAR subroutine 

# Some instruction or other 


Of course, our “clear display” subroutine, comprising just three instruc¬ 
tions (including the RTS), is a trivial example that is hardly worth mak¬ 
ing into a subroutine in the first place. However, let’s suppose that this 
subroutine actually contained, say, 100 lines of code. In this case, the 
ability to call the routine multiple times from different places in the main 
body of the program, as opposed to recreating this code over and over 
again, is going to save us a lot of time (writing the code) and memory 
(storing it). 

Multiple return points from within a subroutine 

A subroutine may contain multiple RTS (“return from subroutine”) 
instructions. For example, let’s assume we have a subroutine called 
TEST that compares the contents of the accumulator to some value 
that has been assigned to a constant label called tstval (“test value”). 
If the value in the accumulator is less than the value associated with 
TSTVAL, we will want to write the letter “S” (“smaller”) to the main 
display; if the two values are equal, we will want to write the letter “E” 
to the main display; and if the value in the accumulator is greater than 
the value associated with tstval, we will want to write the letter “G” 
to the main display: 
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########## Start of "test" subroutine 


TEST: 

CMPA 

TSTVAL 

# 

Compare ACC 

with TSTVAL 


JC 

[GREATER] 

# 

The value in ACC is greater 


JZ 

[EQUAL] 

# 

The values 

are equal 

SMALLER: 

LDA 

$53 

# 

ASCII code 

for 'S' 


STA 

[MAINDISP] 

# 

Write code 

to main display 

RETURNl: 

RTS 


# 

Return from 

subroutine 

EQUAL; 

LDA 

$45 

# 

ASCII code 

for 'E' 


STA 

[MAINDISP] 

# 

Write code 

to main display 

RETURN2: 

RTS 


# 

Return from 

subroutine 

GREATER: 

LDA 

$47 

# 

ASCII code 

for 'G' 


STA 

[MAINDISP] 

# 

Write code 

to main display 

RETURNS: 

RTS 


# 

Return from 

subroutine 

########## 

End of 

"test" subroutine 



Observe the use of three different RTS instructions. Each of these has ex¬ 
actly the same effect, which is to pop the return address off the top of the 
stack, load it into the program counter, and return to the point in the 
program that called this subroutine in the first place. 

Pushing the ACC before calling a subroutine 

One of the things of which we have to be aware with regard to the CLEAR 
subroutine we created earlier is that it modifies the contents of the accu¬ 
mulator (in reality, it’s hard to think of a subroutine that wouldn’t). 

In some cases, this may be a problem. For example, let’s assume 
that we wish to write a question mark character (“?”) to the main display, 
but first we wish to clear the display. Suppose that a program to perform 
this task was created as follows: 


BEFORE: 

LDA 

$3F 

# 

Load 

ACC with ASCII code for "?" 


JSR 

[CLEAR] 

# 

JSR = 

= "Jump to subroutine" 

AFTER: 

STA 

[MAINDISP] 

# 

Copy 

ACC to display 


: # Body of the program 

########## Start of "clear display" subroutine 

CLEAR: LDA CLRCODE # Load accumulator with clear code 

STA [MAINDISP] # Write clear code to main display 

RETURN: RTS # RTS = "return from subroutine" 

########## End of "clear display" subroutine 
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Observe the three lines highlighted in gray. In this case, we have a prob¬ 
lem, because immediately after we’ve loaded the accumulator with $3F 
(the ASCII code for a question mark) we call the clear subroutine, 
which overwrites the contents of the accumulator with the code used to 
clear the display. 

This is obviously a contrived example, and we could easily resolve 
this particular situation by relocating the LDA $3F instruction such that 
it appeared after the JSR. However, the point is that we often find 
ourselves in a similar situation, which is that at some stage in 
the future we are going to need the current contents in the accumula¬ 
tor, but we are poised to call a subroutine that will overwrite these 
contents. So let’s assume that we have to maintain the relative locations 
of the LDA, JSR, and STA instructions in the main body of the 
program. 

One solution is to push the contents of the accumulator onto the 
stack before we call the subroutine, and to subsequently retrieve them by 
popping the accumulator off the stack after we return from the subrou¬ 
tine as follows (note the lines highlighted in gray): 



LDA 

$3F 

# 

Load ACC with ASCII code for "?" 

BEFORE: 

PUSHA 


# 

Push the ACC onto the stack 


JSR 

[CLEAR] 

# 

JSR = "Jump to subroutine" 

AFTER: 

POPA 


# 

Pop the ACC off the stack 


STA 

[MAINDISP] 

# 

Copy ACC to display 


: # Body of the program 

########## Start of "clear display" subroutine 

CLEAR: LDA CLRCODE # Load accumulator with clear code 

STA [MAINDISP] # Write clear code to main display 

RETURN: RTS # RTS = "return from subroutine" 

########## End of "clear display" subroutine 

Pushing the ACC after calling a subroutine 

One problem with our previous solution is that we will have to push and 
pop the accumulator every time we call this particular subroutine. As an 
alternative, we can remove the push and pop instructions from the main 
body of the program and relocate them into the subroutine itself as fol¬ 
lows (note the lines highlighted in gray): 
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BEFORE: LDA $3F # Load ACC with ASCII code for "?" 

JSR [CLEAR] # JSR = "Jump to subroutine" 

AFTER: STA [MAINDISP] # Copy ACC to display 

: # Body of the program 

########## Start of "clear display" subroutine 


CLEAR: 

PUSHA 


# 

Push the ACC onto the stack 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Write clear code to main display 


POPA 


# 

Pop the ACC off the stack 

RETURN: 

RTS 


# 

RTS = "return from subroutine" 


########## End of "clear display" subroutine 

Passing parameters into a subroutine 

Let’s assume that we wish to create a subroutine called getbig that will 
compare two 8-bit numbers and return the one with the largest value. 
Let’s further assume that we want to be able to call this subroutine from 
different points in the main program and that the source of the two 
numbers to be compared may vary from one call to another. 

One way to address this is—you guessed it—^based on the stack. 
First consider some preparations we might make in the body of the pro¬ 
gram prior to calling our subroutine: 



LDA 

$32 

# 

Load ACC with a number 

FIRST: 

PUSHA 


# 

Push it onto the stack 


LDA 

$45 

# 

Load ACC with another number 

SECOND: 

PUSHA 


# 

Push it onto the stack 


JSR 

[GETBIG] 

# 

Jump to the subroutine 

RESULT: 

POPA 


# 

Retrieve the result 


As usual, this is a very contrived case because we already know which is 
the bigger of the two numbers without having to call the subroutine. In 
the real world, however, the two numbers could have come from a vari¬ 
ety of sources; for example, we could have read two buttons from the 
calculator’s keypad and wish to compare their codes. 

One key point here is that the two numbers are pushed onto the 
stack before we call the subroutine, so we can regard them as parameters 
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being passed into the subroutine. Another key point is that our subrou¬ 
tine is going to leave the result (the biggest number) on the top of the 
stack such that we can use a popa to pop it off the stack into the accu¬ 
mulator as soon as we return from the subroutine. 

In order to understand how our subroutine performs its magic, we 
first need to have a clear picture as to the state of the stack when we enter 
the subroutine. Let’s assume that the stack pointer was initialized with 
$EFFF [Figure 3-16(a)], that the popa instruction associated with the 
label RESULT happens to occur at address $5000, and that the program 
snippet shown above reflects the first time the stack has been used 
thus far. 

In this case, as soon as the CPU has executed the pusha instruction 
associated with the FIRST label, the stack will appear as shown in Figure 
3-16(b). Similarly, once the CPU has executed the pusha associated with 
the SECOND label, the stack will appear as shown in Figure 3-16(c). And 
after the CPU has executed the JSR instruction, which causes a copy of 
the return address ($5000) associated with the popa instruction at label 
RESULT to be pushed onto the stack, the situation will appear as shown 
in Figure 3-16(d). 

Last but not least, once the subroutine has finished and used an 
RTS (“return from subroutine”) to return to the main body of the pro¬ 
gram (just prior to actually executing the popa at label result), the 
stack will appear as shown in Figure 3-16(e). 

Now let’s focus on the state of the stack when we actually enter the 
subroutine [Figure 3-16(d)]. It’s immediately obvious that we have a 
slight problem in that the numbers we wish to compare are located at the 
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Figure 3-16. What’s happening on the stack. 
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bottom of the stack underneath the return address of $5000. Let’s bear 
this in mind as we consider how we might go about implementing our 
GETBIG subroutine itself: 


########## 

Start of 

"find biggest number" subroutine 

## 

Pop and 

save the 

return address 

GETBIG: 

POPA 


# 

Pop MS byte of return address 



STA 

[GB_RAD] 

# 

Store it away 

GB_ 

_GLSA: 

POPA 


# 

Pop LS byte of return address 



STA 

[GB_RAD+1] 

# 

Store it away 

## 

Pop and 

compare 

the two numbers 

GB_ 

_GET2 : 

POPA 


# 

Pop the 2nd number off the stack 



STA 

[GB_TEMP8] 

# 

Store it away 

GB_ 

_GET1: 

POPA 


# 

Pop the 1st number off the stack 



CMPA 

[GB_TEMP8] 

# 

Compare it to the 2nd number 

GB_ 

_WHIGH: 

JC 

[GB_TIDY] 

# 

The 1st num (in the ACC)is bigger 



LDA 

[GB_TEMP8] 

# 

The 2nd num {in temp) is bigger 

## 

Push the larger 

number and 

return address back onto the stack 

GB_ 

_TIDY: 

PUSHA 


# 

Push bigger number onto stack 



LDA 

[GB_RAD+1] 

# 

Retrieve LS byte of return address 



PUSHA 


# 

Push it onto the stack 

GB_ 

_PMSA: 

LDA 

[GB_RAD] 

# 

Retrieve MS byte of return address 



PUSHA 


# 

Push it onto the stack 

GB_ 

_RET: 

RTS 


# 

RTS = "return from subroutine" 

########## 

Reserve 

temporary 

storage for this subroutine 

GB_ 

_RAD: 

.2BYTE 


# 

Two bytes for the return address 

GB_ 

_TEMP8 : 

.BYTE 


# 

A one byte temp location 


########## End of "find biggest number" subroutine 

Note that all of the internal labels associated with this routine start 
off with the same two letters. This is a simple technique to help ensure 
that we don’t try to reuse the same labels in multiple subroutines. 

Also note that we reserve several bytes for temporary storage at the 
end of this subroutine (shown highlighted in gray). The first, GB_RAD, is 
a two-byte location that we are going to use to store the return address 
when we pop it off the stack. The second, gb_temp8, is just a one-byte 
temporary location. 

Let’s take a brief stroll through this subroutine. The first thing we 
do is to pop the most-significant byte of the return address off the top of 
the stack and store it in the most-significant byte of our two-byte 
GB_RAD field. Next (at label GB_glsa), we pop the least-significant byte 
of the return address off the top of the stack and store it in the least-sig¬ 
nificant byte of our gb_rad field. 
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Now (at label gb_get2), we pop the second number (that we wish 
to use in our comparison) off the top of the stack and squirrel it away in 
our GB_TEMP8 location, and then (at label gb_get1) we pop the first 
number off the top of the stack into the accumulator, at which point 
we’re really ready to rock and roll. 

The GMPA (“compare accumulator”) is used to compare the first 
number (that’s currently stored in the accumulator) with the second 
number (that’s currently stored in our GB_TEMP8 location). If the num¬ 
ber in the accumulator is the larger, the carry flag will be set to 1, in 
which case the JC (“jump if carry”) instruction (at label gb_whigh) will 
cause us to jump to label gb_tidy. Otherwise, the JG instruction will 
fail and we will load the accumulator with the larger value that is stored 
in our GB_TEMP8 location.^ 

The point is, that by the time we get to label gb_tidy, we know 
that the accumulator contains the larger number, so we push this value 
onto the stack. Next, we load the accumulator with the least-significant 
byte of the return address (from the least-significant byte of our 
GB_RAD field) and push this onto the stack. Then we load the accumu¬ 
lator with the most-significant byte of the return address (from the 
most-significant byte of our gb_rad field) and push this onto the 
stack. 

Thus, when we reach the gb_ret label, just before we execute the 
RTS (“return from subroutine”) instruction, the stack contains the 
largest of the two numbers ($45) and the return address ($5000) as 
shown in Figure 3-17(a). 

This means that, when we execute the RTS, the return address is 
popped off the stack and copied into the program counter, leaving the 
result (the largest number) on the top of the stack from whence it can be 
accessed by the body of the program [Figure 3-17(b)]. 

It now becomes obvious that we can play all sorts of cunning 
games. For example, when a subroutine is called, we know its return ad¬ 
dress is stored on the top of the stack. If we wished, our subroutine could 
pop this address off the top of the stack and replace it with a completely 
different address. This new return address would subsequently be used 
by an RTS instruction that doesn’t know any better. Of course this sort of 
thing is not recommended practice per se, and it makes debugging your 

^Of course, the two values may be equal, but in this case it doesn’t matter which one is 
returned! 
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Figure 3-17. The stack before and after the RTS instruction. 


program extremely difficult, but a trick like this can occasionally come in 
really handy. 

Nested subroutines 

It’s important to note that there is nothing to prevent a subroutine from 
calling one or more sub-subroutines. Similarly, these sub-subroutines 
might themselves call sub-sub-subroutines ad infinitum. This situation, 
which is very common, is referred to as nesting or nested subroutines. 


This would be a rather good time to perform Lab 3e, in which a subroutine is used to display the hex 
codes associated with a number of bytes in memory. 


Recursion 


The term recursion comes from the Latin recursi, meaning “running 
back.” In a mathematical context, recursion refers to an expression in 
which each term is generated by repeating a particular mathematical 
operation. 

By comparison, in the context of a computer program, when a sub¬ 
routine (or function or procedure) calls itself, that subroutine is said to 
be “recursive.” For example, if the body of the program calls a subrou¬ 
tine named SUBA, and SUBA subsequently calls itself, then this would be 
a classic example of recursion. 

In the case where the recursion involves a series of subroutines— 
for example, subroutine SUBA calls subroutine SUBB, and then subb 
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calls SUBA, then SUBA calls SUBB again, and so on—this group of sub¬ 
routines are said to be “mutually recursive.” 

The canonical example of a recursive function is a factorial. For 
example, 5! (which indicates “the factorial of 5”) is evaluated as 5 x 4 x 
3x2x1 = 120. For a positive integer n, this can be represented as: 

If n = 1, then factorial n = 1, otherwise factorial n = nx factorial (n - 1) 

That is, the factorial of some integer n (where n is greater than 1) is equal 
to n multiplied by the factorial of (n - 1), where the factorial of (n - 1) is 
itself equal to (n - 1) multiplied by the factorial (n - 1 - 1), and so forth. 

In practice, recursion can be mind-bogglingly complicated, and it’s 
usually a lot easier to use a more standard alternative such as creating a 
simple loop that uses a variable as a counter. On the other hand, every 
now and then one runs across a task for which a recursive implementa¬ 
tion provides the most elegant solution. 

The most important point to remember if you are creating a recur¬ 
sive function is to fully define some “end condition” that will terminate 
things; otherwise your subroutine may well end up calling itself forever. 


This would be a good time to perform Lab 3f, in which we use a recursive subroutine to display a 
String of characters in reverse order. 


Self-Modifying Code 

It should not be surprising to see a program modifying data values; for 
example, consider the following program snippet: 



LDA 

[TEMPS] 

# 

SHIFT: 

SHL 


# 


STA 

[TEMPS] 

# 

TEMPS: 

.BYTE 

$04 

# 


Load ACC from temp location 
Shift the value left by one bit 
Store ACC to the temp location 

Reserve temp loc and initialize it 


When we reserve the 1-byte location called temps, we initialize it with a 
value of $04 in hexadecimal (%00000100) in binary. But, as we see from 
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our program, at some stage we load this data value into the accumulator, 
shift it left by one bit, and store the result ($08 in hexadecimal or 
%00001000 in binary) back into the temporary location.® 

What isn’t quite so obvious is that a program can also modify its 
own instructions. As a simple example, consider a slight modification 
to our previous program (modifications are shown highlighted in 
gray): 



LDA 

STA 

$71 

[SHIFT] 

# 

# 

Load ACC with opcode for SHR 

Store it to location SHIFT 


LDA 

[TEMPS] 

# 

Load ACC with value in temp 

location 

SHIFT: 

SHL 


# 

Shift the value left by one 

bit 


STA 

[TEMPS] 

# 

Store it back into the temp 

location 

TEMPS: 

.BYTE 

$04 

# 

Reserve temp loc and initialize it 


When the program is first assembled, the memory location associated 
with the SHIFT label will be assigned a value of $70, which is the op¬ 
code for a SHL (“shift left”) instruction. But when the program is 
run (before it reaches our shl instruction), we load the accumulator 
with a value of $71, and then we use the STA [shift] instruction to 
store this value in the memory location associated with the SHIFT 
label. 

The point is that $71 is the opcode for a SHR (“shift right”) instruc¬ 
tion. Thus, when the program reaches the SHIFT label, it will actually 
shift the contents of the accumulator right by one bit, and store the result 
($02 in hexadecimal or %00000010 in binary) back into the temporary 
location.^ 

Don't do it, but if you must... 

Of course, we are in no way recommending this as an everyday prac¬ 
tice. Debugging programs that feature this type of self-modification can 

^Shifting a value left by one bit is the equivalent of multiplying it by 2 (we shall consider 
this in more detail in Chapter 4). 

'’Shifting a value right by one bit is the equivalent of dividing it by 2 (once again, we shall 
consider this in more detail in Chapter 4). 
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bring the strongest among us to our knees. Generally speaking, this 
sort of coding would be considered to be very, very naughty, and 
programmers who use these techniques usually deserve to be soundly 
chastised. 

However, now we’ve opened this Pandora’s box, we may as well 
mention that there are several different flavors of self-modifying code. 
One class is a program that “tweaks” existing instructions as discussed 
above. Every now and then, one runs across a task for which this type of 
self-modifying implementation provides a surprisingly elegant and 
efficient solution. 

Another flavor of self-modifying code is “on-the-fly” code genera¬ 
tion, whereby a program may generate a whole batch of new instructions 
(and possibly data) in some free area of the computer’s memory and 
then transfer control to these new instructions. 

Although this latter case may seem a little weird, it is actually not 
uncommon in such things as graphical applications, in which the pro¬ 
grammer is striving for extreme speed. In this case, it may be possible to 
generate a special-purpose routine to perform a specific set of operations 
and then execute this routine faster than would be possible in the case of 
a preexisting, general-purpose routine. This is because the general-pur¬ 
pose routine may be carrying a lot of “baggage” around to make it 
“general-purpose” in the first place. 


Interactive Laboratories 


If you haven’t already done so, you really need to take the time to per¬ 
form the following interactive laboratories that you’ll find towards the 
back of this book: 


Lab 3a: Using Logical Instructions, Shifts, and Rotates 
Lab 3b: Understanding the Program Counter (PC) 

Lab 3C: Using the Index Register (X) 

Lab 3ll: Using the Stack and Stack Pointer (SP) 

Lab 3e: Using Subroutines 
Lab 3f: Using Recursion 
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Review 

This chapter introduced the logical instructions (and, or, and xor), 
the shift instructions (SHL and SHR), and the rotate instructions (rolC 
and RORC); the program counter (PC), the index register (X), and the 
stack and stack pointer (SP); and subroutines, recursion, and self-mod¬ 
ifying code. 

1) What would be the result of AND-ing the binary values 10011001 
and 01101101 together? How about OR-ing and XOR-ing these 
values together? 

2) Summarize any similarities and/or differences between (a) logical 
and arithmetic shift left instructions and (b) logical and arithmetic 
shift right instructions. 

3) If the accumulator originally contained 00111IOO 2 , what would it 
contain following a SHL instruction and what value would be in the 
carry flag? Assuming the same initial value, what would be the con¬ 
tents of the accumulator and carry flag following a SHR instruction? 
Now, assuming an initial value of 11000011 2 , what would be the 
contents of the accumulator and carry flag following (a) a SHL in¬ 
struction or (b) a SHR instruction? 

4) If the accumulator originally contained 00111IOO 2 and the carry flag 
originally contained 1, what would be the contents of the accumula¬ 
tor and carry flag following (a) a ROLC instruction or (b) a RORC 
instruction? 

5) Summarize the actions of the program counter (PC), index register 
(X), and stack pointer (SP). 

6) What is the name of the instruction used to copy the value in the ac¬ 
cumulator onto the stack? When this operation is performed, is the 
stack pointer incremented or decremented? 

7) What is the name of the instruction used to take a value off the 
top of the stack and copy it into the status register? When this 
action is performed, is the stack pointer incremented or decre¬ 
mented? 

8) Summarize the actions that occur when a JSR (“jump to subrou¬ 
tine”) instruction is performed. 
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9) Summarize the actions that occur when an RTS (“return from sub¬ 
routine”) instruction is performed. 

10) Define recursion in the context of subroutines. Try to think of an 
example in which recursion might be used (different to the examples 
presented in the interactive laboratories associated with this 
chapter). 
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Unsigned Binary Numbers 

In order for computers to work with numbers, we first have to decide 
which numbers we wish to represent, and then we need to determine ex¬ 
actly how we are going to represent them. As we will come to discover, 
almost every aspect of this is more complicated than you might at first 
suppose. As a simple example, do we wish to represent natural numbers, 
whole numbers, or integers? 

Natural (counting) numbers: 1, 2, 3, 4, 5,..., “ 

Whole numbers: 0, 1, 2, 3, 4, 5,..., “ 

Integers: -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5,..., “ 

Note that the oo symbol represents infinity, meaning “boundless,” 
“limitless,” or “without end.” Also, by default, any number without a mi¬ 
nus sign is assumed to be positive. This latter point is relevant, because we 
shall begin by considering only the positive integers (which correspond to 
the whole numbers). Since we know that we are going to consider only 
positive quantities, we don’t need to worry about representing the sign of 
these values. 

Another point to consider is that numbers written by hand with 
pencil and paper can be as large as we wish (limited only by the size of the 
paper and our endurance). By comparison, the size of numbers stored 
and mapiulated inside a computer is dictated by the physical elements 
used to represent them. 

As we discussed in Chapters 1 and 2, our virtual computer’s memory 
is only 8 bits wide (similarly for its data bus). One bit can represent two 
distinct binary values: 0 and 1. Two bits can represent 2^ = 4 distinct bina¬ 
ry values: 00, 01,10, and 11. Three bits can represent 2^ = 8 distinct binary 
values: 000, 001, 010, 011,100,101,110, and 111, and so forth. Thus, 8 
bits can be used to represent 2® = 256 binary values, which can, in turn, be 
used to represent positive integers in the range Ojo to 255io (Figure 4-1). 


Just in case anyone should happen to ask, with respect to referencing numerical values in figures 
and words, there are two types of numbers, carinal and ordinal. 


A cardinal number such as 1,2, 3,... (“one,” “two,” “three,” ...) is used in counting to indicate quantity 
but not order. 


By comparison, an ordinal number such as 1st, 2nd, 3rd,... (“first,” “second,” “third,” ...) indicates its 
position in a series or order. 
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Memory 




2^ = 128's column Bit? (MSB) 
2® = 64's column Bit 6 
2® = 32's column Bit 5 
2“* = 16's column Bit 4 
2® = 8's column Bit 3 

2^ = 4's column Bit 2 

I' = 2's column Bit 1 

2° = rs column Bit 0 (LSB) 


One 8-bit byte in the memory 


i i 1 i 1 i i 1 


00000000 
0 0 0 0 0 0 0 1 
0 0 0 0 0 0 1 0 
0 0 0 0 0 0 1 1 
0 0 0 0 0 1 0 0 


0 = $00 
1 = $01 
2 = $02 

3 = $03 

4 = $04 


1111110 1 —- 
11111110 —- 

11111111 —- 

\ _ ^ _ / 

Unsigned binary values 


= 253 = $FD 

= 254 = $FE 

= 255 = $FF 

Decimal Hex 


Figure 4-1. Using eight bits to represent unsigned binary numbers. 


Whenever we’re dealing with computers, we typically start count¬ 
ing things from zero; thus, the bits forming an 8-bit byte are numbered 
from bit 0 to bit 7. This may seem a little weird the first time you see it, 
but it actually makes a lot of sense, because bits 0 through bit 7 represent 
the 2® through 2’ columns of a binary number, respectively. Bit 0 is also 
known as the least-significant bit (LSB), because it represents the least sig¬ 
nificant value. Similarly, bit 7 is known as the most-significant bit (MSB), 
because it represents the most significant value. 

Remember that we’re only considering positive quantities here, which 
means we don’t need any way to represent the sign of these numbers. For 
this reason, these values are referred to as unsigned binary numbers. 

Adding Unsigned Binary Numbers 

The process of adding binary numbers is identical in concept to working 
in decimal, but it can be a little tricky the first time you do it so we’U take 
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Figure 4-2. Adding decimal numbers. 


things gradually. Let’s start by considering a standard decimal addition 
(Figure 4-2). 

We commence with the least-significant digits, which are in the 
one’s column [Figure 4-2(a)]. As we see, the one’s column contains 1-1-3 
= 4, so there are no surprises here. When we move to the ten’s column 
[Figure 4-2(b)], we find 8 -H 5 = 13, which gives us a result of 3 in the 
ten’s column and a carry of 1 into the hundred’s column. Thus, when we 
reach the hundred’s column [Figure 4-2(c)], we see 6 -H 2 -l- (1) = 9 
[where the ( 1 ) in parentheses was carried over from the ten’s column]. 
Finally, we’re back on home ground in the thousand’s column with 
5 -t- 3 = 8 [Figure 4-2(d)]. 

The point about adding in decimal is that we do it so often we 
don’t even think about it. Even the process of generating a carry in one 
column and using it in the next doesn’t give us any pause. Now let’s pon¬ 
der the process of adding two unsigned binary numbers together, 
OIOIOIOI 2 and OIIIOIOO 2 , which represent 85^0 and II 610 in decimal, 
respectively (Figure 4-3). 

As usual, we commence with the least-significant digits (the bit 0 
column), which are 1 -I- 0 = 1 in this example [Figure 4-3(a)]. Moving on 
to the bit 1 column, we see 0 -H 0 = 0 [Figure 4-3(b)]. 

This isn’t too difficult, is it? But wait\ What’s this? The bit 2 column 
contains a brace of ones [Figure 4-3(c)]. Don’t Panic! This is just like 


The number to which another number is to be added is called the augend, from the Latin augendum, 
meaning “a thing to be increased” (this would be the 5,681 value in the example shown in Figure 4.2). 


By comparison, a number that is added to another number is called the addend, from the Latin addere, 
meaning “to add” (this would be the 3,253 value in the example shown in Figure 4-2). 


The result from the addition of two or more numbers is called the sum, from the Latin summa, from the 
feminine of summus, meaning “highest.” 
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(a) Bit 0 


0 10 10 10 1 

+ 0 1 1 1 0 1 o[^ 

= T 


(b) Bit 1 


0 10 10 10 1 
+ 0 1 1 1 0 i[oJo 

= oT 


(c) Bit 2 


0 10 10 10 1 
+ 0 111 0^0 0 

= 0 0 1 


Carry 


(d) Bit 3 


0 10 1 

r-n 

1 0 1 

0 111 

£ 

0 1 

0 


10 0 1 


(e) Bit 4 




0 1 0 
+ oil 


0 10 1 
0 10 0 


0 10 0 1 


(f) Bits 


0 1 
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0 

10 10 1 

0 1 

1 

10 10 0 


001001 


(5 

0 

1 
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1 1 1 
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1 
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£ 

1110100 

= 

1 

001001 

1 

1001001 


Figure 4-3. Adding unsigned binary numbers. 


generating a carry in decimal. That is, 1 + 1 = IO 2 in binary (2 in deci¬ 
mal), which gives us a result of 0 in the bit 2 column and a carry of 1 into 
the bit 3 column. Thus, when we reach the bit 3 column [Figure 4-3(d)] 
we see 0 -t- 0 -t (1) = 1 [where the (1) in parentheses was carried over 
from the bit 2 column]. 

Based on our newfound knowledge, the bit 4 column holds no 
dread for heroes such as we [Figure 4-3(e)]. In fact, we sneer contemptu¬ 
ously as we once again calculate that 1 -t 1 = IO 2 (in binary), which gives 
us a result of 0 in the bit 4 column and a carry of 1 into the bit 5 column. 
Similarly, we scoff when we reach the bit 5 column itself [Figure 4-3(f)], 
because 0 -I- 1 -I- (1) = IO 2 (in binary), which gives us a result of 0 in the 
bit 5 column and a carry of 1 into the bit 6 column. 

There may, however, be much gnashing of teeth and rending of 
clothing when we reach the bit 6 column [Figure 4-3(g)], because now 
we have to add three Is together! But hold hard for just a moment. Let’s 
take a step back and put things in perspective. All we’re talking about is 
adding three Is together, and how difficult can this be? In fact it’s not 
difficult at all, because 1 -I- 1 -I- (1) = II 2 in binary (3 in decimal), which 
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In the Middle Ages/ it was common practice to use the word piu (from the Latin plus, meaning 
“more”) to indicate an addition. It was also common to use the Latin et, meaning “and.” For example, “6 
piu 2” or “6 et2” were often used to indicate ^^6plus 2” or “d and 2” or “d add 2” in modern terms. 

Some manuscripts from around the 1350s show a symbol that looks like a modern “+” that is believed to 
be an abbreviation of the word et. 

In 1489, the “+” symbol appeared for the first time in print in a book written by the German 
mathematician Johann Widmann. In this case, it was associated with a numerical quantity and used to 
indicate a surplus in business problems. Over time, however, the “+” symbol was increasingly used to 
indicate an addition operation or a positive number. 


gives us a result of 1 in the bit 6 column and a carry of 1 into the bit 7 
column. 

Last, but not least, we can race to the finish line that is the bit 7 col¬ 
umn, because 0 -h 0 -h (1) = 1. Thus, OIOIOIOI 2 + OIIIOIOO 2 = IIOOIOOI 2 
in binary (or 85-1- 116 = 201 in decimal). 


Building a Binary Adder 

As we discussed in Chapters 1 and 3, computers are built out of simple 
logic gates such as ANDs, ORs, and XORs, which are, in turn, construct¬ 
ed out of transistors. If we were designing a computer, one of the things 
we would have to build would be an adder. In this case, our first step 
might be to consider constructing a functional block that could add just 
two bits together (Figure 4-4). 

Even though we’re adding two bits together, this would actually be 
referred to as a “1-bit adder” because it generates a 1-bit result. More 
correctly, it would be classed as a “1-bit full adder” because it includes 
the cin (“carry-in”) and cout (“carry-out”) signals as discussed below. 

The symbol provides a pictorial view of the adder, whereas the 
truth table describes the relationships between its inputs (on the left) and 
outputs (on the right).^ In the case of the inputs, a and b are the two bits 
to be added together, while cin is the carry-in from the previous stage. 
Meanwhile, the s (for “sum”) output represents the result of the addi¬ 
tion, while cout is the carry-out to the next stage. 

^The period in European history between Antiquity and the Renaissance, often dated 
from 476 AD to 1453 AD. 

^Transistors, logic gates, and truth tables are introduced in excruciating detail in the book 
Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), 2nd Edition, ISBN: 
0-7506-7543-8. 
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1 

0 

1 

1 

0 
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1 

0 

1 

0 
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1 

1 

1 

1 
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(a) Symbol (b) Truth table 


Figure 4-4. Adding two bits together (along with a carry-in bit). 


Purely for the sake of interest (we don’t really need to know this 
but, generally speaking, the more we know, the happier we are), we 
could construct such an adder from two AND gates, two XOR gates, and 
a single OR gate as shown in Figure 4-5. 

But we digress. What do we mean when we talk about “carry-in 
from the previous stage” and “carry-out to the next stage”? Well, in the 
case of a computer with an 8-bit data bus (like our virtual computer) 
we really want an 8-bit adder that can add two 8-bit numbers, and one 
way to achieve this is to connect eight of our simple adders together 
(Figure 4-6). 

Observe that we’ve named our signals a[7],a[6],a[5], and so 
on (using what is referred to as a vector notation), as opposed to calling 
them a7, a6, a5, and so on (where this latter form would be referred to 


XOR 



s (sum) 


cout 


Figure 4-5. Constructing an adder from primitive logic gates. 
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COUt 


a[7] b[7] a[6] b[6] a[5] b[5] a[4] b[4] a[3] b[3] a[2] b[2] a[1] b[1] a[0] b[0] 
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cout cin 
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cout cin 


cout cin 


cout cin 
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cout cin 


cout cin 


cout cin 

s 


s 


s 


s 


s 


s 


s 


s 


BitT^^ BitT^^ BitT^^ BitT^^ BitT^^ BitT^”^ Bit 0 ^ 


s[7] s[6] s[5] s[4] s[3] s[2] s[1] s[0] 

Figure 4-6. Creating an 8-bit adder. 


as a scalar notation). To all intents and purposes, the two notations are 
functionally equivalent. The advantage of the vector form is that it allows 
us to easily and efficiently reference ranges (groups) of signals like 
a [ 7 : 0 ] (meaning a [ 7 ] , a [ 6 ] , a [ 5 ],. . ., all the way to a [ 0 ]). 

In the case of the simple unsigned binary additions we’re consider¬ 
ing here, the cin (“carry-in”) signal to the bit 0 stage would be connect¬ 
ed to a logic 0. Bearing this in mind, if you return to the two binary 
numbers we added together in Figure 4-3 and applied one of these num¬ 
bers to the a [ 7 : 0 ] inputs and the other to the b [ 7 : 0 ] inputs, the cor¬ 
rect result would appear on the s [ 7 : 0 ] outputs. 

The advantage of this type of adder is that it’s relatively simple to 
understand and construct. However, there is a disadvantage in that each 
stage has to wait for the output from the previous stage to become valid. 
That is, the bit 1 adder can’t complete its calculation until the carry-out 
signal from the bit 0 adder becomes valid, the bit 2 adder can’t complete 
its calculation until the carry-out from the bit 1 adder is valid, and so 
forth. Thus, this type of adder is known as a ripple adder (or a ripple carry 
adder) because the intermediate results “ripple” through it. (It is possible 
to create more sophisticated adders that can add aU of the bits together 
simultaneously, but these are outside the scope of this book.) 


The ADD Instruction 


Before we proceed further, we should note that our virtual computer 
supports an ADD instruction, which adds a byte of data to the current 
contents of the accumulator. For example, consider the addition illus¬ 
trated in Figure 4-3; one possible assembly code version of this addition 
would be as follows: 
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LDA 

[NUMA] 

# 

Load ACC with value 

in NUMA 

ADD 

[NUMB] 

# 

Add value 

in NUMB 


STA 

[RESULT] 

# 

Store the 

result in 

RESULT 


NUMA: 

.BYTE 

%01010101 

# 

85 in 

decimal, 

$55 

in hex 

NUMB: 

.BYTE 

%01110100 

# 

116 in 

decimal, 

$74 

in hex 

RESULT: 

.BYTE 


# 

Store : 

result here 



Inside the CPU, the add instruction causes two 8-bit values to be pre¬ 
sented to an adder function similar (in concept) to the one shown in 
Figure 4-6. The way in which the above program snippet works can be 
visualized as illustrated in Figure 4-7. 

At point (1), the LDA [NUMA] instruction loads the accumulator 
with the data byte from the memory location associated with the NUMA 
label. At point (2), the ADD [NUMB] instruction causes the current value 
in the accumulator to be added to the data byte from the memory loca¬ 
tion associated with the numb label. Note that the add instruction causes 
the cin (“carry-in”) signal to the adder to be forced to logic 0. Also ob¬ 
serve that the cout (“carry-out”) signal from the adder is loaded into the 


NUMA in Memory 


NUMB in Memory 



RESULT in Memory 


Figure 4-7. Adding two 8-bit numbers together. 
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C (carry) status flag and the result from the addition is stored back in the 
accumulator (thereby overwriting its previous contents). Finally, at point 
(3), the STA [RESULT] instruction stores the current contents of the ac¬ 
cumulator (the result from the addition) into the byte in memory associ¬ 
ated with the RESULT label. 


The Carry Flag 

Now let’s consider the cout (“carry-out”) signal in a little more detail. 
This signal is used to indicate whether or not the result from the addition 
was too big to be held in our 8-bit accumulator. 

The key point to remember here is that, assuming we’re working 
with unsigned binary numbers, our 8-bit fields can be used to represent 
positive integers in the range 0 to 255. When we add two 8-bit values 
such as OIOIOIOI 2 and OIIIOIOO 2 together, this returns an 8-bit result: 
IIOOIOOI 2 . In this case (which equates to 85 -t 116 = 201 in decimal), the 
cout signal from our adder would be 0, thereby indicating that the result 
will fit in our 8-bit accumulator. 

By comparison, when we add two 8-bit values such as IOIOOIOO2 
and OIIIOIOO2 together, this returns a 9-bit result: 10001 IOOO2. In this 
case (which equates to 164 -I- 116 = 280 in decimal), the cout signal 
from our adder would be 1, thereby indicating that the result will not fit 
in our 8-bit accumulator. (The cout signal will be 1 for any addition 
that results in a value greater than 255.) 

The point is that, when performing an addition, the value on the 
cout signal is stored in the carry flag. We can subsequently test this flag 
and respond accordingly—by displaying an error message, for exam¬ 
ple—using one of our JC (“jump if carry”) or JNC (“jump if not carry”) 
instructions. Alternatively, in the case of the multibyte additions dis¬ 
cussed below, we can visualize the C (carry) flag as forming the ninth bit 
in the result. 


Prior to the invention of the character, equality was usually indicated by a word such as aequales or 
aequantur, from the Latin aequlis, meaning “even” or “level” (for example, “6 + 2 aequales 8”). 


The first use of the modern equal symbol appeared in a 1557 AD book called The Whetstone of Witte, which was 
authored by the English mathematician Robert Recorde (1510-1558). In this tome, Recorde noted: “I will sette as I 
doe often in woorke use, a paire of paralles, or Gemowe lines of one lengthe, thus “=” bicause noe 2 thynges can be 
moare equalle.” 
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Multibyte Additions and the 
ADDC Instruction 


It would obviously be somewhat limiting to work only with positive inte¬ 
gers in the range 0 to 255. The solution is to use multiple bytes to repre¬ 
sent each number. For example, let’s suppose that we decide to use two 
bytes (16 bits) to represent an unsigned binary number. In reality, these 
bytes would be located in adjacent locations in memory [Figure 4-8(a)], 
but we can visualize them as being rearranged to form a single 16-bit val¬ 
ue comprising a most-significant byte (MSB) containing bits 15 to 8 and 
a least-significant byte (LSB) containing bits 7 to 0 [Figure 4-8(b) and 
Figure 4-8(c)]. 

In this case, our two bytes can assume any one of 2^® = 65,536 dif¬ 
ferent binary patterns from 00000000000000002 tollllllllllllllll 2 , 
which can be used to represent positive integers in the range 0 to 65,535 
in decimal (or $0000 to $FFFF in hexadecimal). 

Now let’s consider some assembly code that can add two of these 
16-bit numbers together and store the result in a 16-bit field: 


LDA 

[NUMA+l] 

# 

Load ACC with LSB of 

NUMA 

ADD 

[NUMB+1] 

# 

Add LSB of NUMB 


STA 

[RESULT+1] 

# 

Store LSB of result 

in RESULT 

LDA 

[NUMA] 

# 

Load ACC with MSB of 

NUMA 

ADDC 

[NUMB] 

# 

Add MSB of NUMB 


STA 

[RESULT] 

# 

Store MSB of result 

in RESULT 


NUMA: 

.2BYTE 

$1234 

# 

4660 

in decimal 

NUMB: 

.2BYTE 

$2468 

# 

9320 

in decimal 

RESULT: 

.2BYTE 


# 

Store 

result here 


In particular, observe the use of the addc (“add with carry”) instruction 
for the second portion of the addition (the line highlighted in gray). We 
can visualize the way in which the above program snippet works as illus¬ 
trated in Figure 4-9. 

At point (1), the LDA [NUMA+1] instruction loads the accumulator 
with the LSB of the number associated with the numa label. At point (2), 
the ADD [NUMB+1] instruction causes the current value in the accumula¬ 
tor to be added to the LSB of the number associated with the numb label. 
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$nnnn - 2 
$nnnn - 1 
$nnnn 
$nnnn + 1 
$nnnn + 2 
$nnnn + 3 
$nnnn + 4 


(a) Two adjacent 
bytes in memory 


Memory 




(b) Rearrange 
the two bytes 


Bit 15 Bits, , 

^_u 

MS Byte 


Bit 7 Bit 0 
LSByte | 



(c) Vizualize them 
as a 16-bit value 


Figure 4-8. Visualizing two bytes in memory forming a single value. 


Note once again that the ADD instruction causes the cin (“carry-in”) sig¬ 
nal to the adder to be forced to logic 0. As before, the cout (“carry-out”) 
signal from the adder is loaded into the C (carry) status flag and the re¬ 
sult from the addition is stored back in the accumulator (thereby over¬ 
writing its previous contents). Next, at point (3), the STA [RESULT+1] 


Mem. loc. NUMA 
(MSBofNUMA) 


Mem. loc. NUMB 
(MSB of NUMB) 


Mem. loc. NUMA + 1 
(LSBofNUMA) 


Mem. loc. NUMB + 1 
(LSBofNUMB) 
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(3) STA [RESULT+1] 
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(LSB of RESULT) 


Figure 4-9. Adding two 16-bit numbers together. 
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instruction stores the current contents of the accumulator (the LSB por¬ 
tion of the addition) to be stored in the LSB of the field associated with 
the RESULT label. 

Now things start to get interesting. At point (4), the LDA [NUMA] 
instruction loads the accumulator with the MSB of the number associat¬ 
ed with the NUMA label. At point (5), the ADDC [NUMB] instruction caus¬ 
es the current value in the accumulator to be added to the MSB of the 
number associated with the numb label. In this case, however, the addc 
(“add with carry”) instruction causes the cin (“carry-in”) signal to be 
presented with the current value in the C (carry) flag. As usual, the cout 
(“carry-out”) signal from the adder is loaded into the C (carry) flag and 
the result from the addition is stored back in the accumulator (once 
again overwriting its previous contents). Finally, at point (6), the STA 
[RESULT] instruction stores the current contents of the accumulator 
(the MSB portion of the addition) to be stored in the MSB of the field as¬ 
sociated with the RESULT label. 

The key to all of this is the combination of the add and addc in¬ 
structions. When we use the add to sum the least-significant bytes of our 
two numbers, it forces the adder’s cin (“carry-in”) input to logic 0. Fur¬ 
thermore, in this case we are treating the carry flag as being the ninth bit 
in the result. Even if the carry flag contains a 1, this doesn’t mean that 
the result is too big, because we still have the most-significant bytes to 
consider. When we subsequently use the addc to sum the most-signifi¬ 
cant bytes of our two numbers, it causes the current value in the carry 
flag (the carry-out from the previous addition) to be used as the carry-in 
value for this addition. It may help to think of the contents of the carry 
flag acting like the baton in a relay race and being passed from one run¬ 
ner to another. 

Of course, we could use more bytes to represent our numbers if re¬ 
quired. For example, 3-byte (24-bit) values can assume any one of 2^^^ = 
16,777,216 different binary patterns, which can be used to represent pos¬ 
itive integers in the range 0 to 16,777,215 in decimal (or $000000 to 
SFFFFFF in hexadecimal). Similarly, 4-byte values can assume any one of 
2^2 = 4,294,967,296 different binary patterns, which can be used to repre¬ 
sent positive integers in the range 0 to 4,294,967,295 in decimal (or 
$00000000 to $FFFFFFFF in hexadecimal).^ The only thing to remember 

^See also the discussions in Chapter 6 with regard to using values of arbitrary (and 
dynamically variable) precision. 
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is to use an add instruction to sum the least-significant bytes followed by 
ADDC instructions for the remaining bytes. 


This would be a good time to perform Lab 4a, in which we construct a testbench program that weTl 
use to verify the integer math subroutines we create throughout the course of this chapter. Next, work your 
way through Lab 4b, in which we create a general-purpose subroutine to perform 16-bit additions (we will be 
using this subroutine as part of the integer-based calculator program we are going to build in Chapter 5). 


Subtracting Unsigned Binary Numbers 

Unsigned binary numbers can be subtracted from each other using a 
process identical to that used for decimal subtraction. For reasons of 
efficiency, however, computers rarely perform subtractions in this way; 
instead, they perform these operations using complement techniques. 

This does require a little thought, but once you’ve wrapped your 
brain around it you’ll find it to be a lot simpler than you might suppose. 
And, as usual, we’ll take things step by step. Let’s start by considering a 
standard decimal subtraction so as to ensure we’re all tap-dancing to the 
same drumbeat (Figure 4-10). 

Don’t worry; we won’t overdo this. The important point (at least in 
this example) occurs when we reach the ten’s column [Figure 4-10(b)]. 
We start by wanting to subtract 3 from 2, but 3 is bigger than 2, so we 
borrow 1 from the hundreds column. This means that we subtract 1 
from the 6 in the hundreds column of the minuend (see note), leaving 5; 
and then we use our borrowed 1 to augment the 2 in the tens column of 
the minuend to form 12. Thus, our ten’s column now requires us to sub¬ 
tract 3 from 12, leaving 9; and when we reach the hundred’s column, in¬ 
stead of subtracting 2 from 6, we now subtract 2 from 5, leaving 3. 


Borrow-i-r' 

5 

02 

5 @2 5 @2 



5628 56 

2 8 5 

^28 5628 

3 2 - 3 2 

^4^-3 

^3 4 ^ - l3|2 3 4 

4 = 

9 4 = 

394 = 2394 


(a) One's (b) Ten's (c) Hundred's (d) Thousand's 

Column Column Column Column 


Figure 4-10. Subtracting decimal numbers (the “American borrow”). 
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The number from which another number is to be subtracted is called the minuend^ from the Latin 
minuenduniy meaning “thing to be diminished” (this would be the 5,628 value in the example shown in 
Figure 4-10). 


By comparison, a number that is to be subtracted from another number is called the subtrahend, from the 
Latin subtrahendum, meaning “to subtract” (this would be the 3,234 value in the example shown in Figure 
4-10). 


Last but not least, the result obtained by subtracting one number from another is called the remainder or 
the difference. 


Actually, the above reflects the American method for performing a 
borrow operation. Purely for the sake of interest, the way in which this 
would have been performed in England when the authors were young 
lads (and still is for all we know) is illustrated in Figure 4-11. 

In this case, when we come to performing our borrow operation, 
we again augment the 2 in the ten’s column of the minuend with a 1 bor¬ 
rowed from the hundred’s column to form 12. However, rather than 
subtracting 1 from the 6 in the hundred’s column of the minuend to 
leave 5, we instead add 1 to the 2 in the hundreds column of the subtra¬ 
hend to give 3. Thus, when we come to the hundred’s column, we now 
perform the operation 6 - 3 = 3 (as opposed to 5 - 2 = 3 using the Amer¬ 
ican technique). 

The end result is the same, of course, because we’d be in something 
of a pickle if performing a simple math operation such as an integer sub¬ 
traction gave conflicting results on the opposite sides of the Atlantic 
Ocean. The advantage of the American scheme is that it’s more intuitive 
when it comes to visualizing where the “borrow” comes from; the disad¬ 
vantage comes in the form of the special case that occurs should you 
have to borrow (subtract 1) from the next column when that column 
contains a 0. By comparison, the English approach is slightly less intu¬ 
itive, but there are no special cases. 


5 6 2[^ 

- 3 2 3[4j 

= 4 

(a) One's (b) Ten's (c) Hundred's (d) Thousand's 

Column Column Column Column 

Figure 4-11. Subtracting decimal numbers (the “English borrow”). 
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Just to humor us, quickly perform the following subtraction on a 
piece of paper. If you are used to working with the American scheme, 
then try using the English technique, and vice versa: 

74,654,008 
- 13,995,623 

?? ??? ??? 

The answer, of course, is 60,658,385, but it wouldn’t surprise us if per¬ 
forming this calculation took a little longer than you expected because 
you were using an approach that is unfamiliar. The point is that, in the 
not-so-distant past, the average person was much less familiar with per¬ 
forming even simple math operations, so the folks who did know what 
they were doing came up with tricks to make things easier. 

Nines complement decimal subtraction 

Every number system has something called a radix complement and a di¬ 
minished radix complement associated with it, where the term “radix” 
refers to the base of that number system. With regard to the decimal 
(base-10) system, its radix complement is also known as the tens comple¬ 
ment, whereas its diminished radix complement is referred to as the nines 
complement. 

First, let’s consider our original decimal subtraction (5,628 - 3,234) 
performed using the nines complement technique. The first step is to 
generate our nines complement value, which we achieve by subtracting 
our original subtrahend (3,234) from 9,999 [Figure 4-12(a)]. 

Next we add our nines complement value (6,765) to our original 
minuend (5,628) to generate an intermediate result (12,393) as shown in 
Figure 4-12(b). Finally, we perform an end-around-carry operation, 
which involves taking the most significant “1” from our intermediate re¬ 
sult, moving it into the units (ones) column under that result, and 
adding it to what remains of the intermediate result to generate the final 
result (2,394) as illustrated in Figure 4-12(c). 

The advantage of the nines complement technique is that it’s never 
necessary to perform a borrow operation. The disadvantages are that 
there are more steps than in our regular way of doing things and also 
that we have to perform the end-around-carry operation. 
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9 9 9 9 
3 2 3 4 

6 7 6 5 




5 6 2 8 
+ 6 7 6 5 

1 2 3 9 3 




(a) Subtract original 
subtrahend from 9,999 to 
form nines compiement 


(b)Add nines compiement 
to original minuend to 
generate intermediate result 


5 6 2 8 
+ 6 7 6 5 

=42393 
+ -► 1 

= 2 3 9 4 

(c) Perform end-around-carry 
operation to generate the 
finai resuit 


Figure 4-12. Performing a decimal subtraction using the nines complement technique. 


Tens complement decimal subtraction 

Now consider the same subtraction performed using the tens comple¬ 
ment technique. In this case, we first have to generate a tens complement 
value by subtracting our original subtrahend (3,234) from 10,000 
[Figure 4-13(a)]. 

Next, we add our tens complement value (6,766) to our original 
minuend (5,628) to generate an intermediate result (12,394) as shown 
in Figure 4-13(b). And then we simply drop the carry digit from the 
intermediate result to leave the final result (2,394) as illustrated in 
Figure 4-13(c). 

The main advantage of the tens complement approach is that it is 
unnecessary to perform an end-around-carry, because the carry-out re¬ 
sulting from the addition of the most significant digits is simply dropped 
from the final result. The disadvantage is that, during the process of cre¬ 
ating the tens complement, it is necessary to perform a borrow operation 
for every nonzero digit in the subtrahend (this problem can be overcome 
by first generating the nines complement, adding “1” to the result, and 
then performing the remaining operations as for the tens complement). 


1 0 0 0 0 
- 3 2 3 4 

= 6 7 6 6 



5 6 2 8 
+ 6 7 6 6 

=12394 



5 6 2 8 
+ 6 7 6 5 

=42394 


(a) Subtract original (b) Add tens complement 

subtrahend from 10,000 to to original minuend to 

form tens complement generate intermediate result 


(c) Drop the carry 
digit to generate 
the final result 


Figure 4-13. Performing a decimal subtraction using the tens complement technique. 










86 INTEGER ARITHMETIC 


Ones complement binary subtraction 

The point of all of the above is that similar techniques may be employed 
with binary (base-2) numbers, where the radix complement is known as 
the twos complement and the diminished radix complement is known as 
the ones complement. 

Let’s assume that we wish to subtract OOOIIIIO 2 from OOIIIOOI 2 in 
binary (57 - 30 = 27 in decimal). There’s no point in beating our heads 
against the wall trying to understand a standard binary subtraction—that 
is, subtracting the subtrahend (OOOIIIIO 2 ) directly from the minuend 
(0011IOOI 2 )—^because we simply never do things this way in the real 
world. Instead, we use one of the complement techniques. 

First, we’ll consider a binary subtraction performed using the ones 
complement procedure. In this case, we generate our ones complement 
value by subtracting the subtrahend (OOOIIIIO 2 ) from an all-ones value 
(IIIIIIII 2 ) as shown in Figure 4-14(a). 

The resulting ones complement value (IIIOOOOI 2 ) is now added to 
our original minuend (OOIIIOOI 2 ) to generate a 9-bit intermediate result 
(IOOOIIOIO 2 ), as illustrated in Figure 4-14(b). Finally, an end-around- 
carry operation is performed to generate the final result (OOOIIOII 2 ) 
(which equates to 27 in decimal), as shown in Figure 4-14(c). 

The advantage of the ones complement technique is that it is never 
necessary to perform a borrow operation. In fact, it isn’t even necessary to 
perform a subtraction operation, because the ones complement of a value 
can be generated by simply inverting all of its bits, that is, by exchanging 
all of its Os with Is, and vice versa. This means that even if we were to 
stop here, you already know how to perform a simple binary subtraction 
using only inversion and addition, without any actual nitty-gritty sub- 

11111111 00111001 00111001 


-00011110 

=11100001 



+11100001 

=100011010 



+11100001 

=400011010 


► 1 


(a) Subtract original 
subtrahend from 11111111 
to form ones complement 


(b) Add ones complement 
to original minuend to 
generate intermediate result 


= 00011011 

(c) Perform end-around-carry 
operation to generate the 
final result 


Figure 4-14. Performing a binary subtraction using the ones complement technique. 
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traction being involved at all. But watch in wonder and awe, because 
things are going to get better and better. 

Twos complement binary subtraction 

In the case of a twos complement binary subtraction, we first generate a 
twos complement value by subtracting our original subtrahend 
(OOOIIIIO 2 ) from IOOOOOOOO 2 , as shown in Figure 4-15(a). 

Next, we add the resulting twos complement value (11IOOOIO 2 ) to 
our original minuend (OOIIIOOI 2 ) to generate a 9-bit intermediate result 
of 10001101 12 , as illustrated in Figure 4-15(b). And then we simply drop 
the carry digit to leave the final result (0001101 12 ), which, once again, 
equates to 27 in decimal, as shown in Figure 4-15(c). 

As is usual when using a full complement technique, the advantage 
of the twos complement approach is that it isn’t necessary to perform an 
end-around-carry operation, because the carry digit from the intermedi¬ 
ate result is simply dropped to leave the final value. The disadvantage is 
that, during the process of creating the twos complement value, it is nec¬ 
essary to perform a borrow operation for every nonzero digit in the sub¬ 
trahend. Of course this problem can be overcome by first generating the 
ones complement, adding “1” to the result, and then performing the re¬ 
maining operations as for the twos complement (this point is very im¬ 
portant when it comes to building the arithmetic unit in a computer, as 
we’ll see in the next section). 

However, before we proceed, it’s worth noting that a very useful 
short-cut method is available to us when it comes to generating twos 
complement values by hand. For example, let’s assume that we wish to 
generate the twos complement of our original subtrahend (OOOIIIIO 2 ). 
Commencing with the least-significant bit of the value to be comple¬ 
mented, we copy each bit up to and including the first 1 as illustrated in 


1 00000000 
- 00011110 

= 11100010 



00111001 

+11100010 

=100011011 



00111001 

+11100001 

=400011011 


(a) Subtract original (b) Add twos complement 

subtrahend from 100000000 to original minuend to 

to form twos complement generate Intermediate result 


(c) Drop the carry 
digit to generate 
the final result 


Figure 4-15. Performing a binary subtraction using the twos complement technique. 
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Original value 


(b) Invert any 
remaining bits 


Resulting twos 
complement 


0 0 0 1 1 1 1 0 

\ _ ^ 

A 

To 

1 1 1 0 0 0 1 0 


(a) Copy from LSB up to 
and including the first 1 


Figure 4-16. Shortcut for generating a twos complement by hand. 


Figure 4-16(a); then the remaining bits are simply inverted (the Os are re¬ 
placed with Is, and vice versa) as shown in Figure 4-16(b). 


Building a Binary Subtractor 

If we wished, we could construct a binary subtractor from first principles 
in a similar manner to the way in which we approached the binary adder 
earlier in this chapter. Such a unit could directly subtract one value from 
another, but now our CPU would have to contain two relatively complex 
processing units: the adder and the subtractor. 

As an alternative, computer designers employ some cunning tricks 
derived from the way in which ones and twos complement values 
work. In order to understand this, let’s assume that we have two 8-bit 
binary numbers called A [ 7 : 0 ] and B [ 7 : 0 ]. If we wish to subtract 
the latter value from the former, we can represent this operation as 
follows: 


S[7:0] =A[7:0] -B[7:0] 


In early manuscripts, it was common practice to use the word minus (from the Latin minor, 
meaning “less”) to indicate a subtraction. For example, “6 minus 2” would be used to indicate “6 take away 
2” in modern terms. 

People then started abbreviating the word minus by simply using the letter “m” with a horizontal line 
drawn over the top (m). Still later, they omitted the letter “m,” leaving only the horizontal line. 

This symbol appeared for the first time in print in a 1489 book by the German mathematician Johann 
Widmann. In this case, it was associated with a numerical quantity and used to indicate a deficit in 
business problems. Over time, however, the symbol was increasingly used to indicate a subtraction 
operation or a negative number. 
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Where S [ 7 : 0 ] represents the 8-bit result. Alternatively, as we now 
know, we can represent the same operation as follows: 

S[7:0] = A[7:0] + (twos complement of B [ 7 : 0 ] ) 

Note that we will have to “throw away” the carry-out from this opera¬ 
tion, but that’s a “no-brainer” (in fact, as we shall soon discover, this val¬ 
ue appears as the cout (“carry-out”) signal from our adder, and it is 
stored in the C (carry) status flag as usual). And finally—and this is the 
really important point—the twos complement of a number is equal to its 
ones complement plus 1, so we can actually represent our original sub¬ 
traction as follows: 

S[7:0] = A[7:0] + (ones complement of B [ 7 : 0 ]) + 1 

Now consider the diagram shown in Figure 4-17, which represents the 
portion of the arithmetic logic unit {ALU) inside a computer that actually 
performs additions and subtractions. Don’t panic! This is much less 
complicated than it may at first appear. 

Observe the inverter block, which simply inverts each bit of an 8- 
bit value; that is, it exchanges Os for Is, and vice versa. For example, if the 
inputs to the inverter block are 000111IO 2 , then the outputs from that 


A[7:0] B[7:0] 



Figure 4-17. Block diagram of combined adder/subtractor function. 
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block will be 111000012- Thus, the outputs from the inverter block are 
the ones complement of the main B [ 7 : 0 ] inputs. 

Next, observe the 8-bit multiplexer (“mux” for short). Depending 
on the value presented to its control (“select”) input, the multiplexer 
will either select the unmodified version of the B [ 7 ; 0 ] inputs and 
convey this value to its outputs, or it will select the inverted (ones 
complement) version of the B [ 7 ; 0 ] inputs and convey this value to 
its outputs. 

Finally, observe the 2:1 (“2-to-l”) multiplexer whose output drives 
the adder’s cin (“carry-in”) input. This is controlled by the same 
select signal as the 8-bit multiplexer. 

Now, consider what happens if we wish to perform an addition. In 
this case, the A [ 7 : 0 ] inputs (which feed the adder’s a [ 7 : 0 ] inputs) 
represent the augend. Meanwhile, the select signal causes the 8-bit 
multiplexer to choose the unmodified version of the B [ 7 : 0 ] inputs, 
which represent the addend in this case. The multiplexer conveys this 
value to its outputs, which are used to feed the adder’s b [ 7 : 0 ] inputs. 
The select signal also causes the 2:1 multiplexer to present a 0 to the 
adder’s cin input. Thus, the addition works in exactly the same way as 
was discussed earlier in this chapter. 

By comparison, if we wish to perform a subtraction, the A [ 7 : 0 ] 
inputs (which feed the adder’s a [ 7 : 0 ] inputs) represent the minuend. 
This time, the select signal causes the 8-bit multiplexer to choose the 
value from the inverter; that is, the ones complement of the B [ 7 : 0 ] 
inputs, which are now assuming the role of the subtrahend. This ones 
complement value is fed to the adder’s b [ 7 : 0 ] inputs. Thus, the adder is 
now presented with the following: 

A [ 7 : 0 ] -t- (ones complement of B [ 7 : 0 ] ) -I- cin 

The clever part of all of this is that, in the case of the subtraction, the 
select signal also causes the 2:1 multiplexer to present a 1 to the 
adder’s cin input, which means the adder is actually performing the 
following operation: 

A [ 7 : 0 ] -t- (ones complement of B [ 7 : 0 ]) -t- 1 

And, of course, this is exactly what we wish to do in order to perform the 
complement version of our subtraction. 
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The SUB Instruction 


It should not surprise anyone to discover that our virtual computer sup¬ 
ports a SUB instruction, which subtracts a byte of data from the current 
contents of the accumulator. For example, if we wish to perform the op¬ 
eration OOIIIOOI 2 - OOOIIIIO 2 , one possible assembly code version of 
this subtraction would be as follows: 



LDA 

[NUMA] 

# 

Load ACC with 

NUMA value 


SUB 

[NUMB] 

# 

Subtract value 

in NUMB 


STA 

[RESULT] 

# 

Store 

the result in RESULT 

NUMA: 

.BYTE 

%00111001 

# 

57 in 

decimal, 

$39 in hex 

NUMB: 

.BYTE 

%00011110 

# 

3 0 in 

decimal, 

$1E in hex 

RESULT: 

.BYTE 


# 

Store 

result here 


Inside the CPU, the SUB instruction causes the unmodified version of 
NUMA and the inverted (ones complement) version of NUMB to be pre¬ 
sented to an adder function, and the adder’s cin (“carry-in”) input to be 
presented with a 1 value. The result is automatically stored in the accu¬ 
mulator, while the cout (“carry-out”) signal from the adder is automati¬ 
cally stored in the C (carry) status flag. 

The Borrow Flag 

Just to add to the confusion, when we subtract one binary number from 
another, we don’t actually generate carries but, instead, we generate bor¬ 
rows. Thus, although we typically continue to refer to this status bit as 
the carry flag, it actually ends up containing the status pertaining to any 
requirements for a borrow in the case of a SUB instruction. 

To further muddy the waters, borrows act in an opposite manner to 
carries. By this we mean that if the carry flag contains a 1 following a SUB 
instruction, this indicates a “no borrow” condition; but if the carry flag ends 
up containing a 0, then this reflects the fact that a borrow was generated. 
Due to this inversion, the contents of the carry flag following a SUB instruc- 



92 


INTEGER ARITHMETIC 


tion (or it’s SUBC cousin introduced in the next section) are sometimes re¬ 
ferred to as representing a borrow-out-not or a borrow-not condition. 

In order to fully grasp this concept, let’s remind ourselves that 
we’re still dealing with unsigned binary numbers, in which case an 8 -bit 
field can be used to represent values in the range 000000002 to IIIIIIII 2 
(or 0 to 255 in decimal). First, let’s assume that we wish to perform two 
additions as illustrated in Figure 4-18. 

In the case of Figure 4-18(a), we’re adding 184io and 27iq, which 
means that the result of 211 k, will fit in an 8 -bit field; thus, no carry is 
generated and the carry flag ends up containing a 0. By comparison, if we 
add 184io and 8610 as shown in Figure 4-18(b), the result of 270io is too 
big to store in an 8 -bit field; thus, a carry is generated and the carry flag 
ends up containing a 1 . 

With regard to this second addition, if we consider only the value 
stored in the 8 -bit result field ( 000011 IO 2 in binary), this equates to 14io, 
which is somewhat meaningless in this context. In this case, the carry flag 
simply serves to indicate that the result was too big to fit in an 8 -bit field. 
On the other hand, if we consider the carry flag to also represent the 256s 


NUMA(184io) 



(a) Result < 255, no carry 
generated (carry = 0) 


NUMA(184io) 



(b) Result > 255, carry 
generated (carry = 1) 


Figure 4-18. Carries in the context of unsigned binary additions. 
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column of a 9-bit field, then the result is 1000011IO 2 in binary, which 
equates to the correct answer of 270 jq in decimal. This is, of course, the 
way in which our multibyte additions function when we use the ADDC in¬ 
struction to feed the carry from a previous addition forward into the cur¬ 
rent addition. 

Now let’s consider two subtractions as illustrated in Figure 4-19. In 
the first example [Figure 4-19(a)], we’re subtracting 8610 from 184io. In 
this case, the result of 98io is greater than 0 , so the carry flag ends up con¬ 
taining a 1 , indicating that no borrow was generated. 

By comparison, in the second example [Figure 4-19(b)], we’re at¬ 
tempting to subtract 184^0 from 8610 . The problem is that this results in 
-98 105 which is a negative value. Fiowever, we are currently dealing with 
unsigned binary numbers, which can be used to represent only positive 
values. Thus, the value stored in the 8 -bit result field (10011 1 IO 2 in bina¬ 
ry) equates to 158 10 , which has little meaning in this context. In this case, 
the carry flag ends up containing a 0 , thereby indicating that a borrow 
was generated because the result was too small to fit in our 8 -bit field. 

We will see how this borrow is used in the next section, after which 
we will start to consider signed binary numbers that do allow us to repre¬ 
sent both positive and negative values. 


NUMA(184io) NUMA(86io) 



(a) Result > 0, no borrow 
generated (carry = 1) 


(b) Result < 0, borrow 
generated (carry = 0) 


Figure 4-19. Borrows in the context of unsigned binary subtractions. 
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The symbols < and > are used to represent the concepts less than and greater than, respectively. 
These first appeared in a book caded Artis Analyticae Praxis ad Aequationes Algebraicas Resolvendas (“The 
Analytical Arts Applied to Solving Algebraic Equations”), which was written by the English mathematician 
Thomas Harriot (1560-1621) and published posthumously in 1631. 

Later mathematicians started to combine these symbols with the equality character to give two new 
symbols < and >, meaning less than or equal to and greater than or equal to, respectively. Similarly, the 
symbol ^ is used to indicate inequality or not equal. 

Due to that fact that these special symbols are not always available in word-processing programs and text 
editors, and also the fact that programming languages (and their associated parsers, compilers, and/or 
assemblers) tend to employ only ASCII characters, the character combinations <=, >=, and != are often 
used to represent the concepts of less than or equal, greater than or equal, and not equal, respectively. 


Multibyte Subtractions and the 
SUBC Instruction 


Earlier in this chapter, we discussed the concept of using multiple bytes 
to represent larger numbers than could be held in a single 8-bit field. For 
example, a 2-byte (16-bit) field can assume any one of 2^® = 65,536 dif¬ 
ferent binary patterns, which can be used to represent positive integers in 
the range 0 to 65,535 in decimal (or $0000 to $FFFF in hexadecimal). 

As we previously noted, in the case of multibyte additions, our vir¬ 
tual computer supports two instructions called ADD (“add”) and ADDC 
(“add with carry”). Similarly, in the case of multibyte subtractions, we 
have the corresponding SUB (“subtract”) and SUBC (“subtract with 
carry”) instructions.'^ 

For example, consider some assembly code that can subtract one 
16-bit number called NUMB from another called NUMA and store the result 
in a 16-bit field: 


LDA 

[NUMA+1] 

# 

Load ACC with LSB of 

NUMA 

SUB 

[NUMB+1] 

# 

Subtract LSB of NUMB 


STA 

[RESULT+1] 

# 

Store LSB of result 

in RESULT 

LDA 

[NUMA] 

# 

Load ACC with MSB of 

NUMA 

SUBC 

[NUMB] 

# 

Subtract MSB of NUMB 


STA 

[RESULT] 

# 

Store MSB of result 

in RESULT 


^As opposed to a SUBC (“subtract with carry”) instruction, some assembly languages use 
the mnemonic SUBB (“subtract with borrow”). Irrespective of the mnemonic, these 
would both end up using the carry flag and the same machine code instruction as seen by 
the computer. 
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NUMA: .2BYTE $2056 # 8278 in decimal 

NUMB: .2BYTE $10B8 # 4280 in decimal 

RESULT: .2BYTE # Store result here 

In particular, observe the use of the SUBC (“subtract with carry”) in¬ 
struction for the second portion of the addition (the line highlighted in 
gray). Unlike the SUB instruction, in which the cin (“carry-in”) input to 
the adder is forced to 1, the SUBC instruction causes the current contents 
of the C (carry) flag, representing the borrow from the subtraction of the 
least-significant bytes, to be presented to the adder’s cin input. 

Now consider the least-significant bytes of numa and numb, which 
are $56 (or 8610 in decimal) and $B 8 (or 184^0 in decimal). By some 
strange quirk of fate, these are the same values we used when performing 
the 1-byte subtraction in Figure 4-19(b). In that case, the result was 
meaningless because it was smaller than zero, but the same result does 
have meaning now that we’re dealing with multibyte values. 

Let’s work this problem through by hand in the same way in which 
our virtual computer will execute the assembly code above. The opera¬ 
tion we wish to perform is as follows: 

$2056-$10B8 

First, we use a SUB instruction to subtract the least-significant byte of 
NUMB from the least-significant byte of NUMA. If we were performing this 
subtraction directly, it would appear as follows: 

$56 - $B 8 

But we know that the way in which the computer will actually execute 
this task is to take the ones complement of $B 8 (or %10111000 in bina¬ 
ry), which will return $47 (or %01000111 in binary), to force the adder’s 
cin input to 1 , and to perform the following operation: 

$56 -h $47 -t- 1 

The result is $9E with a carry-out of 0, which will be stored in the carry 
flag. As we now know, this carry-out of 0 reflects a borrow. In turn, this 
indicates that the result is too small (that is, negative) to fit in our 8 -bit 
field, but this isn’t an issue in this case because we have still the most- 
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significant bytes to consider. Now, we use a SUBC instruction to subtract 
the most-significant byte of numb ($10) from the most-significant byte of 
NUMA ($20) This time, we know that the way the computer will execute 
this task is to take the ones complement of $10 (or %00010000 in bina¬ 
ry), which will return $EF (or %11101111 in binary), and to perform the 
following operation: 

$20 + $EF + cin 

In this case, we know that cin will be fed from the current contents in 
the C (carry) flag, and that this value will be 0, representing the borrow 
from the previous subtraction, so the result will be $0F with a carry-out 
of 1. This carry-out of 1 reflects a no-borrow situation, which, in turn, 
indicates that the output from this subtraction will fit in the 8-bit field 
that represents the most-significant byte of our result. In summary, we 
just performed the following multibyte subtraction: 

$2056-$10B8 = $0F9E 

which equates to 8,278io - 4,280io = 3,998io in decimal. 


This would be a good time to work your way through Lab 4c, in which we create a general-purpose 
subroutine to perform 16-bit subtractions (we will be using this subroutine as part of the integer-based calcu¬ 
lator program we are going to build in Chapter 5). 


Sign-Magnitude Representations 

As we’ve come to appreciate, the problem with using unsigned binary 
numbers is that, by definition, they cannot be used to represent negative 
quantities. In the real world, this would obviously be somewhat limiting, 
because we would only ever be able to subtract smaller numbers from 
bigger ones. 

In the case of standard decimal representations, negative values are 
indicated using a minus sign. For example, negative twenty-seven would 
be shown as -27. This is referred to as a sign-magnitude format (that is, a 
sign followed by an associated magnitude), and it means that the only 
difference between a positive quantity like -1-27 and its negative counter¬ 
part -27 is the sign. 

If we wished, we could apply the same sign-magnitude concept to 
binary numbers. For example, assuming we’re dealing with 8-bit values. 
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we could designate the most-significant bit as being the sign bit (where 0 
and 1 in this sign bit indicate positive and negative values, respectively). 
Meanwhile, the remaining seven bits could be used to represent the mag¬ 
nitude of the number. This would allow us to represent negative and 
positive integers in the range -127 to -t-127 (Figure 4-20). 

There are several problems with this format, not the least that we 
now have both positive and negative versions of zero (-1-0 and -0). What 
should happen if we were to compare these values (is -l-O conceptually 
bigger than -0)? 

In fact, if a computer were forced to use sign-magnitude represen¬ 
tations, it would be obliged to perform a whole slew of operations. Even 
in the case of a simple addition of two 8-bit values such as A [ 7 : 0 ] -t- 
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Figure 4-20. Using eight bits to represent sign-magnitude binary numbers. 
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B [ 7 : 0 ], for example, the computer would first have to check the signs 
of the numbers. If the signs were the same (both positive or both nega¬ 
tive), the computer could simply add the two values together (excluding 
the sign bits), because the result would always have the same sign as the 
original numbers. If the signs were different, however, the computer 
would have to compare the two magnitudes to determine which was the 
smaller, subtract this from the larger value, and then ensure that the cor¬ 
rect sign was appended to the result. 

This would be terribly tedious and time-consuming to say the least. 
If only there were some other way.. . 


Signed Binary Numbers 

The cunning ruse underlying the concept of signed binary numbers is 
that the sign bit is used to signify a negative quantity (not just the sign). 
As we originally showed in Figure 4-1, in the case of an unsigned binary 
number, the most significant bit in an 8 -bit field is used to represent 2 ^ 
(the -l-128s column). By comparison, in the case of a signed binary num¬ 
ber, this bit (the sign bit) is now used to represent - 2 ^ (the -128s col¬ 
umn). Meanwhile, the remaining seven bits continue to represent their 
original positive quantities (Figure 4-21). 

This means that we start off with OOOOOOOO 2 representing Ojo as 
usual, and work our way up to 011111112 , which represents -l-127io. 
However, instead of representing -I-128 10 as is the case with an unsigned 
binary number, the value IOOOOOOO 2 now represents -128io- 

As we already noted, even when the sign bit is 1, the remaining bits 
continue to represent positive quantities. Thus, 1000000 12 equates to 
-128io + lio = -127io; IOOOOOIO 2 equates to -128io + 2^0 = -126io; 
IOOOOOII 2 equates to -128io + 2io + lio = -125io, and so on to 
IIIIIIII 2 , which equates to -128io + 64^0 + 32^0 + I 610 + 810 + ^10 + 2 io 
+ lio = ~lio- 

All of this means that an 8 -bit signed binary number can be used to 
represent values in the range -128io to -l-127io- To more fully illustrate 
the differences between the sign-magnitude and signed binary formats, 
consider a positive sign-magnitude decimal number and its negative 
equivalent; for example, +27 and -27. As usual, the numerical digits are 
identical in both cases and only the sign changes. Now consider the same 
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Signed binary vaiues 


One 8-bit byte in the memory 


0 = $00 
■ = +1 = $01 

■ = +2 = $02 

■ = +125 = $7D 

■ = +126 = $7E 

■ = +127 = $7F 

■ = -128 = $80 

■ - -127 = $81 

■ - -126 = $82 

■ = -3 = $FD 

■ - -2 = $FE 

■ - -1 = $FF 

Decimai Flex 


Figure 4-21. Using eight bits to represent signed binary numbers. 


values represented as sign-magnitude binary numbers and signed binary 
numbers (Figure 4-22). 

In the case of the positive and negative sign-magnitude binary 
numbers, only the sign bit changes, whereas the bit patterns for the mag¬ 
nitude components are identical. By comparison, the bit patterns associ¬ 
ated with the positive and negative signed binary numbers are very dif¬ 
ferent. As we know, this is because the sign bit represents an actual 
quantity (-128io) rather than a simple plus or minus; thus, the signed 
binary equivalent of-27io is formed by combining -128 jq with -F 101 jq- 

Good grief Charlie Brown! 

At a first glance, the signed binary concept may appear to be an outra¬ 
geously complex solution to a fairly simple problem. In addition to rep- 
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(a) Sign-magnitude 
binary format 
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(b) Signed binary 
number format 
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Figure 4-22. Comparison of sign-magnitude and signed binary formats. 


resenting an asymmetrical range of negative and positive numbers 
(-128io to +127io in the case of an 8 -bit value), the way in which these 
representations are formed is, to put it mildly, alien to the way we’re 
used to thinking about numbers. 

As you might expect, however, there’s reason behind the (apparent) 
madness, not the least that signed binary numbers only have one version 
of 0 (as opposed to the +0 and -0 inherent in the sign-magnitude for¬ 
mat). Now pay close attention, because this is the really clever part; clos¬ 
er investigation of the two signed binary values shown in Figure 4-22(b) 
reveals that each bit pattern is the twos complement of the other! To put 
this another way, taking the twos complement of a positive signed binary 
value returns its negative equivalent, and vice versa. 

As we shall soon discover, using this format makes our lives much 
easier. In fact, surprising as it may seem, signed binary numbers actually 
make sense at an intuitive level. Consider what happens if we start with 
OOOOOOOO 2 in the accumulator and then loop around incrementing 
(adding one to) the accumulator until we reach IIIIIIII 2 . The next in¬ 
crement will cause the accumulator to overflow and return it to contain¬ 
ing OOOOOOOO 2 . “So what,” you may ask. Well, now consider what hap¬ 
pens if we go the other way; that is, start with OOOOOOOO 2 in the 
accumulator and then decrement (subtract one from) the accumulator, 
which will leave the accumulator containing 1111111 12 . This exactly 
matches what happens in decimal, in that subtracting 1 from 0 results in 
- 1 ; similarly, subtracting 1 from OOOOOOOO 2 (or $00 in hexadecimal) re- 
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suits in 1111111 12 , (or $FF in hexadecimal), which equates to -1 in the 
signed binary format. 

Adding signed binary numbers 

The end result of using signed binary numbers (which may also be re¬ 
ferred to as twos complement numbers) is to greatly reduce the complex¬ 
ity of operations inside a computer. To illustrate why this is so, consider 
one of the simpler operations: addition. Compare the additions of posi¬ 
tive and negative decimal values in sign-magnitude form with their 
signed binary counterparts as shown in Figure 4-23. 

Let’s start by examining the standard decimal calculations on the 
left-hand side of Figure 4-23. The one in Figure 4-23(a) is easy to under¬ 
stand because it’s a straightforward addition of two positive values. How¬ 
ever, even though we are extremely familiar with decimal addition, the 
three other problems in Figures 4-23(b), 4-23(c), and 4-23(d) typically 
require a little pause for thought while we decide exactly how to handle 
the negative values. 

By comparison, the signed binary calculations on the right-hand 
side of Figure 4-23 are all simple additions (note that we have omitted 


Decimal sign- Signed binary (twos 

magnitude values complement) numbers 


/-^-\ 


(a) Add a positive 
to a positive 

5 7 
+ 3 0 

= 8 7 

0 

+ 

001 11001 
00011 110 

01010111 

(b) Add a negative 
to a positive 

5 7 
+ -3 0 

0 

+ 

00111001 

11100010 

= 2 7 

= 

0001101 1 

(c) Add a positive 
to a negative 

-5 7 
+ 3 0 

= -2 7 


+ 

1100011 1 
00011 110 

11100101 

(d) Add a negative 
to a negative 

-5 7 
+ -3 0 


+ 

1100011 1 
11100010 

= -8 7 

= 

10101001 


Figure 4-23. Comparison of sign-magnitude decimal and signed binary 
additions. 
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any carry-out values from these additions for simplicity; such carry-outs 
would be automatically stored in the carry flag). Thus, the advantage of 
the signed binary format for addition operations is apparent: signed bi¬ 
nary values can always be directly added together to give the correct re¬ 
sult, irrespective of whether they represent positive or negative quanti¬ 
ties. That is, when using signed binary numbers, the operations (+a) -I- 
(-Hb), (+a) -t- (-b), (-a) -I- (+b), and (-a) -I- (-b) are all performed in ex¬ 
actly the same way, which is by simply adding the two values together. 
This results in computers that are simpler to design, use fewer logic 
gates, and perform calculations faster. 

Subtracting signed binary numbers 

Now let’s consider the case of subtraction. We all know that 10-7 = 3 
when using decimal arithmetic. We also know that we can obtain the 
same result by negating the right-hand value and inverting the operation; 
that is, 10 + (-7) = 3. 

The same technique is also true for signed binary numbers. In this 
case, however, the negation of the right-hand value is performed by tak¬ 
ing its twos complement rather than changing its sign. For example, con¬ 
sider a generic signed binary subtraction represented by a - b. Generat¬ 
ing the twos complement of b results in (-b), thereby allowing the 
operation to be performed as an addition: a -I- (-b). 

This means that computers don’t require an adder and a subtrac¬ 
tor; instead, they require only an adder and some way to generate the 
twos complement of a number. And, of course, this is exactly what we 
were doing all along when we introduced the concept of binary subtrac¬ 
tion in the context of unsigned binary numbers. 

One final point to ponder before we continue is that it’s up to us to 
decide what the binary values stored in a computer represent at any par¬ 
ticular time. For example, depending on the task we are trying to per¬ 
form, we may consider the 8-bit value llllllll 2 tobean unsigned bina¬ 
ry number, in which case it represents 255 jq in decimal. But a little later 
we may decide to consider the same 1111111 12 value to be a signed 
binary number, in which case it represents -1 jg in decimal. The really 
cool thing is that the computer doesn’t care: it performs additions and 
subtractions exactly the same way, irrespective of whether we are consid¬ 
ering the numbers to represent signed or unsigned quantities [see also 
the discussions on the O (overflow) flag in the next section]. 
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The only problem 

The only problem with the signed binary format is that, due to its asym¬ 
metrical range, the largest negative number cannot be negated. In the 
case of an 8-bit (1-byte) signed binary number, for example, we can’t 
negate -128io to form -l-128io because the largest positive value that’s 
supported is -t-127io- We typically get around this issue by restricting our¬ 
selves to working only with the range -127io to -l-127io in the case of an 
8-bit field. Alternatively, if we are using 16-bit (2-byte) signed binary 
numbers, which can be used to represent values from -32,768 lo to 
4-32,767 io> we will restrict ourselves to working only with the range 
—32,767jo to -l-32,767jo. 


This would be a good time to perform Lab 4d, in which we create a 16-bit negation subroutine; that 
is, one that converts a 16-bit positive signed binary number into its negative counterpart, and vice versa. 


The Overflow Flag 

As we know, the C (carry flag) is used to store any carries generated by 
the ADD and ADDC instructions and any borrows generated by the SUB 
and SUBC instructions. In the case of unsigned binary numbers, the 
carry flag is also used to indicate whether or not the result from the 
operation will fit into the 8-bit accumulator. Sad to relate, however, 
there’s a slight “gotcha” when it comes to working with signed binary 
representations. 

Let’s consider a simple ADD instruction. When we were discussing 
this instruction in the context of unsigned binary numbers, we stated 
that, following the addition, a 0 in the carry flag would indicate that the 
operation was successful; that is, the result fit in the 8-bit accumulator. 

By comparison, a 1 in the C (carry) flag would indicate that the result 
was too large to fit in the accumulator. 

Consider the addition illustrated in Figure 4-24. If we assume that 
we’re working with unsigned binary numbers, then our 8-bit accumula¬ 
tor can represent values in the range Ojo to 255io- In this case, adding 
OIOIOIOO 2 (84io in decimal) to OOIIIOOI 2 (57io in decimal) will result in 
10001IOI 2 (141 10 in decimal). As this value is less than 255i0) it fits in our 
accumulator and the carry flag is loaded with 0. 
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NUMA(84io) 



Figure 4-24. Introducing the O (overflow) flag. 


Now consider what happens if we add exactly the same numbers 
together, but this time we regard them, and the result, as representing 
signed binary values. In this case, our 8-bit accumulator can represent 
values in the range -128io to +127 which means that the result of 
-t-141 10 is too large. Due to the fact that we’re assuming signed binary 
numbers, we would regard the ensuing 10001IOI 2 value as equating to 
-115io, which is meaningless in the context of adding 84io to 57io- 

The problem is that the C (carry) flag doesn’t help us here. Thus, 
the computer also features an O (overflow) status flag, which is gener¬ 
ated as an XOR (exclusive OR)^ of the carry signals going in to and out 
of bit 7 of the result. (The overflow flag works exactly the same way 
with additions and subtractions of positive and negative signed binary 
values.) 

What all of this means is that, if we decide to treat our numbers as 
representing unsigned binary values, then we ignore the O (overflow) flag 
and we use the C (carry) flag to determine whether or not the result fits 
in the accumulator. Alternatively, if we decide to treat our numbers as 
representing signed binary values, then we rely on the O (overflow) flag 


^The concept of the logical XOR function was introduced in Chapter 3. 
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to determine whether or not the result is OK (overflow = 0), or whether 
we have an overflow or underflow condition (overflow =1). 

In order to make use of the overflow flag, the computer supports 
two special jump instructions: JO (“jump if overflow”), which will jump 
if the overflow flag contains a 1, and JNO (“jump if not overflow”) which 
will jump if the overflow flag contains a 0. 

Note that in the case of multibyte additions and subtractions on 
both signed and unsigned binary values, we still use the contents of the 
carry flag to propagate carries and borrows up the line. Following the 
flnal addition or subtraction operation on the most significant bytes of 
unsigned values, we ignore the overflow flag and we test the value in the 
carry flag (in the case of an addition, a 0 in the carry flag tells us that the 
result is OK, whereas a 1 indicates an overflow condition; in the case of a 
subtraction, a 1 in the carry flag tells us that the result is OK, whereas a 0 
indicates an underflow condition). 

By comparison, following the final addition or subtraction opera¬ 
tion on the most significant bytes of signed values, we ignore the carry 
flag and instead test the overflow flag (irrespective of whether we are per¬ 
forming an addition or a subtraction, a 0 in the overflow flag tells us that 
the result is OK, whereas a 1 indicates either an overflow or an underflow 
condition). 


This would be a good time to perform Lab 4e, in which we modify our 16-bit add and subtract rou- 
tines to check the overflow flag and generate an error message if an overflow (or underflow) condition occurs. 


Multiplying Signed Binary Numbers 

Multiplying by shifting left 

Before we plunge headfirst into the fray, it’s worth noting that there’s a 
shortcut to multiplying binary numbers by powers of two (that is, 2^ = 2, 
1} = 4, 2^ = 8, etc.), which is to shift the value to the left by the same 
number of bits as the exponent. 

For example, if we take the binary value 0001101 12 (or +27io in 
decimal) and shift it one bit left, we end up with OOIIOIIO 2 (or +54^0 
in decimal), which is the same as multiplying our original number by 
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A number that is to be multiplied by another is called the multiplicand, from the Latin 
multiplicandum, meaning “to multiply.” By comparison, the number with which another number is to be 
multiplied is called the multiplier. 


The result obtained from the multiplication of two or more numbers is called the product, from the Latin 
producere, meaning “to bring forth.” 


Thus, in the equation 3x6=18, the multiplier is 3, the multiplicand is 6, and the product is 18. (If it seems 
to you that the terms multiplier and multiplicand have been applied the wrong way round, try thinking of 
the above equation in terms of “three sixes are.” 


2^ = 2. Similarly, if we had taken our original number and shifted it 
two bits to the left, we would have ended up with OIIOIIOO 2 (or 
+ 10810 in decimal), which is the same as multiplying our original num¬ 
ber by 2^ = 4. 

This also works for signed (twos complement) binary numbers. For 
example, if we assume the binary value 1110001 02 is in the signed binary 
format (equating to -30io in decimal), then shifting this value one bit to 
the left results in 1IOOOIOO 2 (or - 6 O 10 in decimal). 

High-level computer languages such as the C programming lan¬ 
guage use software tools called compilers to translate their human-read¬ 
able source code representations into the machine code that is to be exe¬ 
cuted by the computer.® Depending on the capabilities of the target 
machine, these compilers may be instructed to look for special cases like 

fred = bert * 2 ; 

where fred and bert are integer variables and the asterisk character 
indicates a multiplication operation. In such a case, the compiler might 
replace this multiplication by a simple shift left. Alternatively, the origi¬ 
nal programmer may decide to do this by hand using 

fred = bert << 1 ; 

which means the variable bert is to be shifted left by one bit and the re¬ 
sult is to be assigned to the variable fred. If fact, when computers were 
less powerful than they are now, programmers used to employ all sorts of 
tricks like this; for example, suppose we wanted fred to be made equal 
to bert multiplied by nine: 

fred = bert * 9; 

^In some cases, an intermediate step may be used whereby the compiler translates the 
source code into assembly language, which is subsequently assembled into machine code. 
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then we could achieve the same effect by means of the following state¬ 
ment: 


fred = (bert « 3) + bert; 

where “(bert << 3)” means “shift bert three bits to the left,” which 
has the same effect as multiplying bert by eight. So the whole expres¬ 
sion equates to “(bert * 8) + bert.” This gives the same result as our 
original “bert * 9” statement, but the “shift and add” approach is a lot 
faster on microcomputers or microcontrollers with limited computa¬ 
tional resources.^ 

Beware! It’s easy to run into trouble here if you aren’t careful. For 
example, if we were to take the binary value 10110110 and shift it one bit 
to the left, we’d end up with 01101100. This is, of course, perfectly ac¬ 
ceptable if we’re considering the accumulator to contain a simple pattern 
of Os and Is, because the result is exactly what we’d expect. However, if 
we’re visualizing these values to represent signed (twos complement) bi¬ 
nary numbers then we have a problem, because we started with 


The now-familiar X symbol was first used to indicate multiplication in the 1631 tome Claris 
Mathematicae (“Key to Mathematics”), which was written by the EngUsh mathematician and clergyman 
William Oughtred (1574-1660).® 

Unfortunately, although the meaning of the X symbol is clear when the operands are numbers (for 
example, 3 X 6 = 18), it can easily be confused in algebraic formulas that use letters to represent variables 
(for example, x X y = z). For this reason, sometime during the 1690s, the German mathematician Gottfried 
von Leibniz (1646-1716) started to use a raised dot to indicate multiplication (for example, x-y = z)?’ 

In his 1659 book Teutsche Algebra (“German Algebra”), the Swiss mathematician Johann Rahn (also 
known as Johann Rhonius, 1622-1676) used the asterisk character to indicate a multiplication (for 
example, 6*3 = 18), and it is this symbol that is now commonly used in computer programming languages 
and on calculator front panels. 


^Depending on the application and the capabilities of the target machine, programmers 
who need as much speed as possible may stiU resort to using tricks like this. 

®In 1621, Oughtred invented the slide rule, which was based on the concept of loga¬ 
rithms. In turn, logarithms were invented by the Scottish mathematician and Laird of 
Merchiston, John Napier (1550-1617). See Appendix D for more details on additional re¬ 
sources, including The History of Calculators, Computers, and Other Stuff on the CD ac¬ 
companying this book. 

^Others may have used the raised dot before Leibnitz, but this convention didn’t really 
catch on until he started to champion it. 

'“Leibniz also invented a mechanical calculator called the Step Reckoner in the 1670s. 
Once again, see Appendix D for more details on additional resources, including The His¬ 
tory of Calculators, Computers, and Other Stuff on the CD accompanying this book. 
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IOIIOIIO 2 (or -74io in decimal), multiplied this value by two by shifting 
it one bit to the left, and ended up with OIIOIIOO 2 (or +IO 810 in deci¬ 
mal), which is obviously incorrect. The problem is that, as per the dis¬ 
cussions associated with Figure 4-21, our 8 -bit accumulator can only 
represent signed binary numbers in the range -128io to -l-127io> which 
means that it isn’t large enough to store the result generated by multiply¬ 
ing -74io by two. 

Decimal multiplication using a "shift-and-add" 
technique 

Modern computers typically have special multiplication units that they 
use to multiply two binary values together (we’ll discuss this in a little 
more detail below). However, early microprocessors didn’t have this 
capability, and neither does our virtual computer, which means that we 
will have to perform multiplication operations using only the simple 
instructions (add, subtract, shift, rotate, etc.) that are available to us. 

One technique for performing multiplication in any number base is 
by means of repeated addition; in decimal, for example: 6x4 = 4-l-4-l-4 
+ 4 + 4 + 4 = 24. Although simple, this technique can be very time-con¬ 
suming if the numbers being multiplied together are large. 

Another technique is based on the concept of “shift-and-add.” As 
usual, we’ll begin by considering a standard decimal multiplication in 
order to ensure that we’re all marching along in step. Suppose we wish to 
perform the operation 3,120io X 33,201 jq. We can visualize this as illus¬ 
trated in Figure 4-25. 

Note that the values chosen for the multiplier and multiplicand 
have no significance beyond the purposes of this example. 

Using this technique, a partial product is generated for each digit in 
the multiplier. Each partial product is a copy of the multiplicand that has 
been multiplied by its associated multiplier digit. Also, each partial prod¬ 
uct is left-shifted by the number of digits equal to the value of the expo¬ 
nent in the multiplier column with which it is associated. For example, 
consider the partial product associated with the units column in the mul¬ 
tiplier (33,201 X 0 = 00,000). As this is the 10° column, the exponent is 0 
(zero), so this partial product is left-shifted by zero digits, which means 
that it isn’t left-shifted at all. In the case of the multiplier’s tens (10*) 
column, the exponent is 1, so this partial product (33,201 X 2 = 66,402) 
is left-shifted by one digit, which corresponds to an additional multipli- 
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Multiplier 
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Figure 4-25. Decimal multiplication using a shift-and-add technique. 


cation by 10. Similarly, the partial product associated with the hundreds 
(10^) column in the multiplier (33,201 X 1 = 33,201) is left-shifted by 
two digits, which corresponds to an additional multiplication by 100. 

And the partial product associated with the thousands (10^) column in 
the multiplier (33,201 X 3 = 99,603) is left-shifted by three digits, which 
corresponds to an additional multiplication by 1000. 

Once all of the partial products have been generated, they are added 
together to give the final product (result). Observe that the width of the 
result (nine decimal digits) equals the sum of the widths of the multiplier 
(five digits) and the multiplicand (four digits). 

Binary multiplication using a "shift-and-add" 
technique 

The same shift-and-add technique as discussed above can also be used 
to multiply binary numbers together. For example, suppose we wish to 
perform the operation OIIIOOII 2 X OOOIOIIO 2 . We can visualize this as 
illustrated in Figure 4-26. 

Once again, a partial product is generated for each digit in the mul¬ 
tiplier. Each partial product is a copy of the multiplicand that has been 
multiplied by its associated multiplier digit. Also, each partial product is 
left-shifted by the number of digits equal to the value of the exponent in 
the multiplier column with which it is associated. Thus, the partial prod¬ 
uct associated with bit 0 in the multiplier, which represents the 2° col¬ 
umn, is left-shifted by 0 bits (that is, it isn’t shifted at all); the partial 
product associated with bit 1 in the multiplier, which represents the 
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/ 







\ 


/ 







\ 

0 

1 

1 

1 

0 

0 

1 

Ij 

X 

0 

0 

0 

1 

0 

1 

1 












0 

0 

0 

1 

0 

1 

1 

0 ^ 









0 

0 

0 

1 

0 

1 

1 

0 

- 








0 

0 

0 

0 

0 

0 

0 

0 

- 

- 







0 

0 

0 

0 

0 

0 

0 

0 

- 

- 

- 

Partial 

- 

- 

- 

- 

0 

0 

0 

1 

0 

1 

1 

0 

- 

- 

- 


Products 

- 

- 

- 

0 

0 

0 

1 

0 

1 

1 

0 







- 

- 

0 

0 

0 

1 

0 

1 

1 

0 








- 

0 

0 

0 

0 

0 

0 

0 

0 







/ 


0 

0 

0 

0 

1 

0 

0 

1 

1 

1 

1 

0 

0 

0 

1 

£j 



16-bit Product 


Figure 4-26. Binary multiplication using a shift-and-add technique. 


2 ^column, is left-shifted by 1 bit; the partial product associated with bit 2 
in the multiplier, which represents the I? column, is left-shifted by 2 bits; 
and so forth. 

As fate would have it, the fact that we’re working in binary actually 
makes things a whole lot easier. In the case of a multiplier bit that’s 0, the 
corresponding partial product is all Os; whereas in the case of a multiplier 
bit that’s 1, the corresponding partial product is simply a copy of the 
multiplicand. 

Once all of the partial products have been generated, they are added 
together to give the final product (result). In this case, the width of the 
result equals the sum of the widths of the multiplier and the multipli¬ 
cand; that is, 8 -t 8 = 16 binary digits. 

Implementing a hardware multiplier for signed (twos 
complement) binary numbers 

One minor “glitch” with binary multiplication using the shift-and-add 
technique presented in the previous section is that, assuming we’re 
working with signed binary numbers, it only works if both the multiplier 
and multiplicand have positive values. We can easily get around this, of 
course, by converting any negative values into their positive counter- 
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parts, performing the multiplication using positive values, and then cor¬ 
recting the sign of the product if necessary. 

For some reason, it’s generally easier to visualize the way in which 
this sort of thing works in terms of a hardware implementation using a 
special block of logic whose sole task is to multiply two binary values to¬ 
gether. For example, consider the block diagram for a hardware multipli¬ 
er intended to multiply two 8 -bit values together (Figure 4-27). 

As usual, this is much less complicated than it might at first appear, 
so don’t be unduly alarmed. Let’s start by considering the 8 -bit multiplier 
in the upper-left corner of this illustration. A direct copy of the multiplier 
is fed to one side of a multiplexer. The multiplier is also presented to a 
block of logic that will generate the twos complement of this value (that is, 
it wiU turn a positive value into its negative counterpart, and vice versa). 


Sign bit Sign bit 



Figure 4-27. Block diagram of an 8-bit x 8-bit hardware multiplier. 







































































112 


INTEGER ARITHMETIC 


The multiplier’s sign bit is used to control a multiplexer. If the sign 
bit is 0, the multiplier represents a positive value, so the sign bit causes 
the multiplexer to select the direct copy of the multiplier and convey this 
value to its outputs. Alternatively, if the sign bit is 1, the multiplier repre¬ 
sents a negative value, in which case the sign bit causes the multiplexer to 
select the output from the twos complement block (where this value is 
the positive equivalent of the multiplier). 

Similar actions are performed on the 8-bit multiplicand in the up¬ 
per-right corner of Figure 4-27. Thus, the multiplier and multiplicand 
values fed into the multiplier array are always positive. The multiplier ar¬ 
ray simultaneously generates all eight partial products, which are fed into 
an adder block that sums them all together. 

At this point, we have to decide whether or not to correct the sign 
of the result (that is, whether we have to convert the output from the 
adder into a negative value). The way in which we do this is rather ele¬ 
gant: consider the rules associated with multiplying positive and negative 
values together: 

-I- multiplied by -i- equals -i- 

-I- multiplied by - equals - 

- multiplied by -i- equals - 

- multiplied by - equals -i- 

Now observe that the two sign bits from the original multiplier and mul¬ 
tiplicand are fed into an XOR gate, and that the output from this XOR 
gate is used to control a multiplexer. From Chapter 3, we know that the 
truth table for an XOR gate is as shown in Figure 4-28. 

If we consider the 0 and I values in this truth table to represent -I- 
and -, respectively, then the output from the XOR gate tells us whether 
the result from our multiplication should be positive or negative. 

The 16-bit output from the adder block is fed directly to one side of 
the multiplexer and also to a block of logic that will generate the twos 
complement of this value (the output from this twos complement block 
is presented to the other side of the multiplexer). In turn, the output 
from the multiplexer represents the final product (result) from the mul¬ 
tiplication. If the output from the XOR gate is 0, the result from the mul¬ 
tiplication should be positive, so the XOR gate causes the multiplexer to 
select the output from the adder block and convey this value to its out¬ 
puts. Alternatively, if the output from the XOR gate is 1, the result from 
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XOR 
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0 

0 
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1 

1 

0 

1 

1 

1 
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Truth Table 


Figure 4-28. Truth table for an XOR gate. 


the multiplication should be negative, so the multiplexer is directed to 
select the output from the twos complement block. 

Some CPUs are equipped with this type of hardware multiplier 
(although in the real world it would feature a few more “bells and whis¬ 
tles”), in which case their associated assembly language will contain a 
MULT (“multiply”) instruction. Sad to relate, simple CPUs, such as the 
one featured in our virtual DIY Calculator, do not contain such a unit. 
This means that they are obliged to implement the multiplication using 
only the basic add, subtract, shift, rotate, and other instructions that are 
available to them. 


This would be a good time to work your way through Lab 4f, in which we create a general-purpose 
subroutine to perform 16-bit multiplications (we will be using this subroutine as part of the integer-based cal¬ 
culator program we are going to build in Chapter 5). 


Dividing Signed Binary Numbers 

Dividing by shifting right 

And so, finally, we turn our attention to division, which is one of the 
trickiest of the basic math operations we have to perform. 


A number that is to be divided by another is called the dividend^ whereas a number that is to be 
divided into another number is called the divisor (this may also be known as the factor if it divides a given 
quantity without leaving any remainder). 


The result obtained from dividing one number by another is called the quotient, from the Latin quotiens, 
meaning “how many times.” And the term remainder refers to anything that is left over when one integer is 
divided by another. 
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Before we tackle this topic, however, it’s worth noting that there’s 
a shortcut to dividing binary numbers by powers of two (that is, 2 ' = 2 , 

1} = 4, 2^ = 8 , etc.), which is to shift the value to the right by the same 
number of bits as the exponent. 

For example, if we take the binary value 01101IOO 2 (or +IO 810 in 
decimal) and shift it one bit right, we end up with 001101IO 2 (or +54io in 
decimal), which is the same as dividing our original number by 2 * = 2 . 
Similarly, if we had taken our original number and shifted it two bits to 
the right, we would have ended up with 0001101 12 (or +27io in decimal), 
which is the same as dividing our original number by 1} = 4. 

Note that, if we divide an odd number like OOOIOOOI 2 (or +17io in 
decimal) by two using this shift right technique, we will end up with 
OOOOIOOO 2 (or +810 in decimal), and the 1 that ends up in the carry flag 
following the shift operation represents the remainder from the division 
(that is, 17 2 = 8 with a remainder of 1). 

Of course, this also works for signed (twos complement) binary 
numbers. For example, if we assume the binary value IIOOOIOO 2 is in 
the signed binary format (equating to - 6 O 10 in decimal), then shifting 
this value one bit to the right results in IIIOOOIO 2 (or -30io in deci¬ 
mal). 

This is very important! With regard to the previous point, it’s im¬ 
portant to note that the reason this works is because our virtual comput¬ 
er’s SHR (“shift right”) instruction is an arithmetic shift right, which 
means that the most-significant bit (the sign bit) is copied back on itself 
(you may wish to review the discussions on arithmetic versus logical 
shifts in Chapter 3; in particular, take a glance at Figure 3-3). 

Performing a division in decimal 

In order to set the scene, let’s first consider the way in which we might 
perform a division operation in decimal; for example, dividing 14^0 into 
662io (Figure 4-29). 

In order to perform this calculation, our thought processes may go 
something like this. We know that we can’t divide 14 into 6 , so we take 
the next option and try to divide 14 into 66 , but how should we set about 
doing this? The majority of us would probably take a stab at it and say: 
“Hmmm, let’s try 3 X 14 = 42. No, that’s too small. How about 5 X 14 = 
70? No, that’s too big. Let’s try 4 x 14 = 56. Yes, that’s about as close as 
we can get.” 
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4 7 -► Result =47 (remainder 4) 

1 4 

4 X 14 = 56-► 

66-56 = 10 -► = 1 0 

▼ 

Drop the 2 to form 102-► 1 0 2 

7 X 14 = 98 -► - 9 8 

102-98 = 4 -► = 4 


) 6 6 2 
-56 


Figure 4-29. Performing a long division in decimal. 


Now, we know that the first digit in our quotient (result) is 4 (from 
the 4 X 14), so we write this down. Next, we subtract 56 from 66 leaving 
10; drop the 2 to form 102; and go through our “Goldilocks and the 
three bears” process again,^^ saying: “6 X 14 = 84, but that’s too small; 8 
X 14 = 112, but that’s too big; 7 x 14 = 98, and that’s just right (or, at 
least, as close as we can get).” 

So we now know that the second digit in our quotient is 7, and we 
write it down. Finally, we subtract 98 from 102 leaving 4, which (remem¬ 
bering that we’re performing an integer division) is too small to be divid¬ 
ed by 14. Thus, our final result is 47 with a remainder of 4. 


As we previously noted, division is conceptually the most complex of the fundamental arithmetic 
operations (+, /), which may serve to explain why there are so many symbols associated with it! 

One common symbol is a vinculum, from the Latin vincre, meaning “to bind” or “to tie together.” In its 
general sense, this refers to a horizontal line drawn over two or more algebraic terms to indicate that they 
are to be treated as a single entity. Figure 4-30(a) shows a vinculum used to bind the values “2 + 1” 
together. Over time, however, it also became common to use a vinculum to represent divisions involving 
only single terms, as illustrated in Figure 4-30(b). 

In the early 1600s, a colon was used to indicate fractions and ratios, such as 3:5 (meaning “three 
fifths”). Sometime later, around the early to mid-1680s, the German mathematician Gottfried von Leibniz 
started to use colons for both fractions and to indicate division operations, as shown in Figure 4-30(c). 

In his 1659 book, Teutsche Algebra (“German Algebra”), the Swiss mathematician Johann Rahn was the 
first to use a symbol called the obelus as illustrated in Figure 4-30(d). More recently, it became common to 
use the forward slash symbol “/”—called a solidus or virgule, as illustrated in Figure 4-30(d), and it is this 
symbol that is now commonly used in computer programming languages and on calculator front panels. 

Last but not least, the symbol used in Figures 4-29 and 4-30(e) (a combination of a vinculum attached to 
the top of a closing parenthesis) first appeared in U.S. textbooks around the early 1880s. Although this 
symbol is now very commonly used in the case of long division problems, it does not have an official name. 


the “suck it and see” approach in the vernacular used by engineers. 
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4 7 


6 

2 + 1 

6 

3 

6:3 

6-3 

6/3 

14 ) 6 5 8 

a) Vinculum 
(multiple terms) 

b) Vinculum 
(single terms) 

c) Colon 

d) Obelus 

d) Solidus 

e) No name 


Figure 4-30. Alternative symbols used to represent division. 


Performing a division in binary 

When it comes to performing a division in binary, we can use a similar 
process to the one we used for decimal; for example, let’s assume that we 
wish to divide OOIO 2 into 011 12 in binary ( 2^0 into 7io in decimal), as 
shown in Figure 4-31. 

In some respects, binary divisions are simpler than their decimal 
cousins, because the divisor can either be directly subtracted from the 
portion of the dividend currently under consideration or it can’t; that is, 
we don’t have to worry about experimenting with different multiples of 
the divisor. 

In the case of this particular example, we know that we can’t divide 
IO 2 into O 2 , so we set the first digit in our quotient (result) to 0. Similarly, 
we know that we can’t divide IO 2 into 01 2 , so we set the second digit in 
the quotient to 0. However, we can divide IO 2 into 01 12 , so we set the 
third digit in our quotient to 1. 

Subtracting IO 2 from 01 12 leaves 01 2 , at which point we drop the 
next 1 from the dividend to form 0112- Once again, we know that we can 
divide IO 2 into 01 12 , so we set the fourth digit in our quotient to 1. This 


0 0 1 I 2 -► Result = 11 2 (remainder 1) 

1 O 2 ) 0 1 1 I 2 
- 1 0 

112 - 102=012 -► = 01 

Drop the 1 to form II 2 -► 0 1 1 

- 1 0 

112-102 = 012 -► = 01 - 


Figure 4-31. Performing a long division in binary. 
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leaves a value of 01 2 , which is too small to be divided by IO 2 . Thus, the fi¬ 
nal result from dividing 011 12 by IO 2 is 1 12 with a remainder of 1 (that is, 
7io divided by 2^0 = 3io with a remainder of 1). 

As we shall see, the algorithm we use to make our calculator per¬ 
form binary divisions only works if both the divisor and dividend have 
positive values. This means that we will have to convert any negative val¬ 
ues into their positive counterparts, perform the division using positive 
values, and then correct the sign of the quotient if necessary. 

Rounding 

Finally, let us turn our attention to the concept of rounding. In order to 
set the scene, let’s assume that we have just performed eight decimal di¬ 
vision operations using a pencil and paper, and that the results from 
these divisions are as follows: 

(a) 27.0 (b) 27.4 (c) 27.5 (d) 27.6 

(e) 28.0 (f) 28.4 (g) 28.5 (h) 28.6 

If we have made the decision to work only with integer values, then we 
will ultimately have to discard any digits to the right of the decimal 
point. We could simply truncate our answers by “throwing” these digits 
away, but if we use these results as part of future operations, we can end 
up with “creeping errors.” As an alternative, we can use the digits to the 
right of the decimal point as part of a rounding algorithm so as to in¬ 
crease the accuracy of the final result. 

In fact, there are a plethora of different rounding schemes (of 
which the truncation approach discussed above is one) that may be used 
depending on the application. The more common techniques are listed 
below. 

• Round-down. Also known as “chopping,” this refers to rounding 
toward 0 or truncating. In this case, the digits to be discarded 
(those to the right of the decimal point for the purposes of these 
discussions) are simply ignored: 

(a) 27.0 ^27 (b) 27.4 ^27 (c) 27.5 ^ 27 (d) 27.6 ^ 27 
(e) 28.0 ^28 (f) 28.4^28 (g) 28.5 ^ 28 (h) 28.6 ^ 28 

• Round-up. This refers to rounding away from 0. In this case, if 
all of the digits to the right of the decimal point are zero, the in- 



teger portion of the result is unchanged; otherwise it will be in¬ 
cremented by 1: 

(a) 27.0 ^27 (b) 27.4^28 (c) 27.5 ^28 (d) 27.6 ^ 28 

(e) 28.0 ^28 (f) 28.4^29 (g) 28.5 ^29 (h) 28.6 ^ 29 

Round-half-up. If the digits to be discarded are greater than or 
equal to 0.5, then the integer portion of the result will be incre¬ 
mented by 1; otherwise it will be left unchanged: 

(a) 27.0 ^27 (b) 27.4^27 (c) 27.5 ^28 (d) 27.6 ^ 28 

(e) 28.0 ^28 (f) 28.4^28 (g) 28.5 ^29 (h) 28.6 ^ 29 

Round-half-down. If the digits to be discarded are greater than 
0.5, then the integer portion of the result will be incremented by 
1; otherwise (if the digits to be discarded are equal to or less than 
0.5) the integer portion will be left unchanged: 

(a) 27.0 ^27 (b) 27.4^27 (c) 27.5 ^27 (d) 27.6 ^ 28 

(e) 28.0 ^28 (f) 28.4^28 (g) 28.5 ^28 (h) 28.6 ^ 29 

Round-half-even. Sometimes referred to as “bankers’ rounding,” 
this is possibly the best (most balanced) of the simple rounding 
techniques, because errors tend to cancel out over the course of 
multiple operations (see also stochastic rounding below). In this 
case, if the digits to be discarded are greater than 0.5, then the in¬ 
teger portion of the result will be incremented by 1. Or if the dig¬ 
its to be discarded are less than 0.5, the integer portion will be left 
unchanged. If the digits to be discarded are equal to 0.5, the inte¬ 
ger portion of the result will be rounded so as to make an even 
number (that is, if the integer portion of the result is already even 
then it will be left unaltered, but if the integer portion of the re¬ 
sult is odd, it will be incremented by 1 (rounded-up) to form an 
even number): 

(a) 27.0 ^27 (b) 27.4^27 (c) 27.5 ^28 (d) 27.6 ^ 28 
(e) 28.0 ^28 (f) 28.4^28 (g) 28.5 ^28 (h) 28.6 ^ 29 

Round-half-odd. This is similar to the previous mode, the differ¬ 
ence being that if the digits to be discarded are equal to 0.5, the 
integer portion of the result will be rounded so as to make an odd 
number: 
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(a) 27.0 ^27 (b) 27.4 ^27 (c) 27.5 ^27 (d) 27.6 ^ 28 
(e) 28.0 ^28 (f) 28.4^28 (g) 28.5 ^ 29 (h) 28.6 ^ 29 

This mode is never used in practice because it never rounds to 
zero, which is often desirable; that is, a result of 0.5 would round 
to 1 instead of 0. 

• Round-ceiling. This refers to rounding toward positive infinity 
( 4 - 00 ). In this case, the integer portion of the result will remain 
unchanged if the discarded digits are all zero or if the number 
is negative; otherwise, it will be incremented by 1 (that is, 
rounded up): 

(a)+27.0^-t27 (b)-t27.4 ^-r28 (c) +27.5^4-28 (d) 4-27.6 ^-t28 
(e)-27.0 ^-27 (f) -27.4^-27 (g)-27.5 ^-27 (h)-27.6 ^-27 

• Round-floor. This refers to rounding toward negative infinity 
(- 0 °). In this case, the integer portion of the result will remain 
unchanged if the discarded digits are all zero or if the number is 
positive; otherwise, it will be incremented by 1: 

(a) 4-27.0 ^ 4-27 (b) -h27.4 ^ -h27 (c) 4-27.5 ^ 4-27 (d) 4-27.6 ^ 4-27 
(e)-27.0 ^-27 (f) -27.4^-28 (g)-27.5 ^-28 (h)-27.6 ^-28 

• Stochastic Rounding. The term stochastic, which comes from the 
Greek stokhazesthai, meaning “to guess at,” refers to a process in¬ 
volving chance or probability by means of a random (or pseudo¬ 
random) variable. The idea here is that, if the digits to be dis¬ 
carded are equal to 0.5, the computer will effectively “toss a 
metaphorical coin into the air” and randomly round the integer 
portion of the result up or down. Although this approach typi¬ 
cally gives the best results over the course of a large number of 
calculations, it is only employed in highly specialized applica¬ 
tions and is rarely found in mainstream usage. This is because 
the results can vary each time a series of calculations are per¬ 
formed, which, apart from anything else, makes this technique 
very difficult to test. 


This would be a good time to work your way through Lab 4g, in which we create a general-purpose 
subroutine to perform 16-bit divisions (we will be using this subroutine as part of the integer-based calculator 
program we are going to build in Chapter 5). 
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Interactive Laboratories 


If you haven’t already done so, create and test the testbench program and 
subroutines described in the following interactive laboratories that you’ll 
find toward the back of this book: We will be using these subroutines to 
build an integer-based calculator as described in Chapter 5. 


Lab 4a: Creating a Testbench Program 
Lab 4b: Creating a 16-bit ADD Subroutine 
Lab4G: Creating a 16-bit SUBTRACT Subroutine 
Lab4d: Creating a 16-bit NEGATE Subroutine 
Lab 4e: Checking for Overflow in the ADD and SUBTRACT 
Subroutines 

Lab4f: Creating a 16-bit MULTIPLY Subroutine 
Lab 49: Creating a 16-bit DIVIDE Subroutine 


Review 

This chapter introduced the concepts of signed versus unsigned binary 
numbers; adding and subtracting binary numbers; multiplying and divid¬ 
ing binary numbers; and the use of the carry, borrow, and overflow flags. 

1) Summarize the concepts of natural (counting), whole, and integer 
numbers. 

2) Document the bit-by-bit addition of the two binary numbers 
00101010 and 00110111 in a style similar to that used in Figure 4-3. 

3) What range of decimal numbers could be accommodated using a 
7-bit sign-magnitude binary format? How about a 9-bit sign-magni¬ 
tude binary format? 

4) What would be the binary equivalents of the decimal values +44^0 
and -44io using an 8-bit sign-magnitude binary format? 

5) What range of decimal numbers could be accommodated using a 7- 
bit signed binary format? How about a 9-bit signed binary format? 

6 ) What would be the binary equivalents of the decimal values +68io 
and -68io using an 8-bit sign-magnitude binary format? 
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7) Generate the ones complement equivalents of the following signed 
binary values: OOIIOOII 2 , IIOOIIOO 2 , OIOIOOII 2 , and IOIOIIOO 2 . 

8 ) Convert the decimal values -ISOjo and -140io into 8-bit signed 
binary numbers, add them together, and describe the resulting 
contents of the carry and overflow flags. 

9) Convert the decimal values -130io and -l-23io into 8-bit signed bina¬ 
ry numbers and multiply them together using a shift-and-add tech¬ 
nique. 

10) Convert the hexadecimal values 84^6 and 24i6 into their 8-bit signed 
binary counterparts, and then divide the binary equivalent of 84ig by 
the binary equivalent of 24 jg. What are the values of the quotient 
and the remainder? What would be the final value of the quotient if 
we were using the following rounding techniques: round-down, 
round-up, round-half-up, round-half-down, round-half-even, 
round-half-odd, round-ceiling, and round-floor? 
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1 In this chapter we will consider: 

L • Usage models 

^ • The infix, prefix, and postfix notations 

• The order of operations 

r • The precedence of operators 

C • Direct algebraic logic 

• The Polish and reverse Polish notations 
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A Few Decisions 

The purpose of this chapter and its associated laboratories is to create a 
simple four-function (+, and /) calculator that can be used as the 
basis for further experimentation. But, before we plunge into the fray, 
there are a few decisions that have to be made. 

How to represent numbers inside 
the computer 

The first thing we have to establish is how we wish to store and manipu¬ 
late numbers inside the computer. Based on our discussions in the previ¬ 
ous chapters and laboratories, we have made the decision to work with 
2-byte signed binary integer values that we will use to represent numbers 
in the range -32,767lo to -1-32,767 jo¬ 
lt’s important to note, however, that there are a number of differ¬ 
ent schemes we could adopt. These alternative approaches are discussed 
in more detail in Chapter 6 and also on the DIY Calculator website at 
www.DIYCalculator.com. 

In what form(s) to input and output values 

Another consideration involves how we wish to enter and display 
numbers. For example, the testbench program we created to test the 
math routines in the labs associated with Chapter 4 required us to 
enter and display values as four hexadecimal digits. By default, 
however, we typically prefer to work in decimal. Thus, for the 
purposes of this calculator, we will make the decision to create input 
and output routines that allow us to enter and display values in deci¬ 
mal. To be more specific, our input routines will allow us to enter 
values in decimal and they will then convert these values into their 
signed binary equivalents for storage and manipulation. Similarly, 
our output routines will take the signed binary values stored inside 
the calculator and convert them into their decimal equivalents for 
display. 

As discussed in Chapter 6, these preliminary routines could be 
extended in the future to allow values to be entered and displayed in 
binary, decimal, and hexadecimal. 
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Which math functions to implement 

The next step in the process involves deciding which math functions we 
wish to perform. For the purposes of this first-pass calculator, we will 
offer only the four fundamental binary operators (-t-, and /). The 
reason these are referred to as “binary” operators is that they require 
two operands. 

Our first-pass calculator will also support the unary operator -t/-, 
which will be used to invert the sign of the value currently on display 
(the term “unary” is employed because this operator requires only a sin¬ 
gle operand). For example, if the display originally shows a value of +42, 
then clicking the +/- key will negate this value inside the computer and 
also display this negated form of -42. Similarly, clicking the +/- key once 
more will return the value to its positive form and display -I-42. 

As is discussed in Chapter 6, once we have our first-pass calculator 
up and running, we may decide to extend our selection of math func¬ 
tions to include more interesting operations. 

Which usage model to adopt 

In this context, the term “usage model” refers to the way in which we in¬ 
tend to interact with our calculator. For example, suppose we wish to 
perform the operation 

3-t6-2 = 7 

How do we intend to communicate our requirements to the calculator? 
Your knee-jerk reaction may be to create input routines to allow us to 
enter the following keystrokes: 

[3] [+] [6] H [2] [=] 

Known as infix notation (because the operators are embedded be¬ 
tween the operands), this is certainly a possibility. However, it does raise 
all sorts of complications for the unwary. Thus, for the purposes of our 
first-pass calculator, we shall adopt another approach known as reverse 
polish notation (RPN). 

The remainder of this chapter is devoted to explaining some of the 
considerations associated with the various possible usage models. As is 
discussed in Chapter 6, once we have our first-pass calculator up and 
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running, we may decide to modify our input routines to support a 
different usage model. 


Infix, Prefix, and Postfix Notations 

In a way, we’re jumping a bit ahead of ourselves by introducing these 
topics here, but “biting the bullet” now will make our subsequent discus¬ 
sions easier to understand. So let’s leap into action by stating that there 
are three fundamental notations we can use to represent mathematical 
equations: 

Infix notation: 1 + 2 

Prefix notation: -1-12 

Postfix notation: 12-1- 

In the case of an infix notation, with which we are most familiar, 
operators like +, -, *, and / are placed between the operands. In this case, 
we can use the operators to indicate the end of the numbers. Thus, the 
actual keystrokes we would use with an infix-based input routine would 
be as follows: 

Keystrokes for infix notation: [1] [-t-] [2] [=]... 

Note the use of the equals (“=”) key to indicate the fact that we’ve 
reached the end of the equation and wish to see the final result. 

By comparison, in the case of a prefix notation, the operators are 
placed before the operands. This leads to a problem in that we need some 
way to indicate to the calculator’s input routines when we’ve reached the 
end of a number; otherwise, the two keystrokes [1] and [2] could be mis¬ 
takenly assumed to represent the number 12. For this reason, a calculator 
based on a prefix notation requires an extra “Enter” key to indicate the 
end of a number. Thus, the actual keystrokes we would use with a prefix- 
based input routine would be as follows: 

Keystrokes for prefix notation: [-I-] [1] [Enter] [2] [Enter] 

In this case, we don’t actually require an equals (“=”) key because 
the operation will be performed and the result displayed as soon as the 
second operand has been entered. 

Last, but not least, in the case of a postfix notation, the operators 
are located after the operands. Once again, this requires the use of a 
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special “Enter” key to indicate the end of a number. Thus, the actual key¬ 
strokes we would use with a postfix-based input routine would be as 
follows: 

Keystrokes for postfix notation: [1] [Enter] [2] [-t] 

Once again, we don’t actually require an equals (“=”) key when us¬ 
ing this approach because the operation will be performed and the result 
displayed as soon as the operator key has been pressed. 

Finally, before we move on to the “meat” of this chapter, it’s im¬ 
portant to note that you can, in fact, mix operators and operands when 
using both the prefix and postfix schemes as follows: 

“Infix notation: 1*2 + 3 

Prefix notation: +*123 or +3*12 

Postfix notation: 312*+ or 12*3 + 

Using the stack 

The notation we are actually going to implement in our first-pass calcu¬ 
lator is of the postfix variety, so let’s consider the examples presented 
above in a little more detail. Let’s start with the first variant: 

1st Postfix example: 3 12* + 

Actual keystrokes: [3] [Enter] [1] [Enter] [2] [Enter] [*] [+] 

As we previously discussed, the “Enter” key is used to indicate the 
end of a number. As each value is entered, it is pushed onto the top of 
the stack. In this case, pressing the “Enter” key after the number “2” is 
optional because the “+” operator can also be used to indicate the end of 
the number; but assuming that this “Enter” is used will aid us in our dis¬ 
cussions. Thus, the state of the stack after the third number has been en¬ 
tered will be as shown in Figure 5-1(a). (Note that these are high-level 
representations of the stack that do not reflect the actual number of bytes 
being used to represent each value.) 

When the multiplication (*) operator is keyed in, whatever two 
numbers are on the top of the stack will be popped off the stack, multi¬ 
plied together, and the result will be placed back on the stack [Figure 5- 
1(b)]. Similarly, when the addition (+) operator is keyed in, whatever two 
numbers are on the top of the stack will be popped off the stack, added 
together, and the result will be placed back on the stack [Figure 5-1(c)]. 
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Memory 

(Stack) 



Memory Memory 

(Stack) (Stack) 




(a) After Srd 
number entered 


(b) After * operation (c) After + operation 
has been performed has been performed 


Figure 5-1. The stack during the first postfix example. 


Now, let’s consider the state of the stack during the course of our 
second postfix variant, which was as follows: 

2nd Postfix example: 12*3 + 

Actual keystrokes: [1] [Enter] [2] [Enter] [*] [3] [Enter] [+] 

In this case, pressing the “Enter” key after the number “2” and the 
number “3” would be optional; once again, however, assuming that these 
keystrokes are performed will aid us in our discussions. Once the num¬ 
ber “2” has been entered, the stack will be as shown in Figure 5-2(a). 

When the multiplication (*) operator is keyed in, whatever two 
numbers are on the top of the stack will be popped off the stack, multi¬ 
plied together, and the result wiU be placed back on the stack [Figure 5- 
2(b)]. When the third number is then entered, the stack wiU be as shown 
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Figure 5-2. The stack during the second postfix example. 
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in Figure 5-2(c). Finally, when the addition (+) operator is keyed in, 
whatever two numbers are on the top of the stack will be popped off the 
stack, added together, and the result will be placed back on the stack 
[Figure 5-2(d)]. 

This postfix approach may seem a little counterintuitive at first, so 
why would anyone wish to go this way? Aha! Therein lies a story.. . 


Order of Operations 

The term “order of operations” refers to a convention that dictates which 
operations should be performed in which order. For example, consider 
the following expression: 

1 + 2*3 = ? 

What do you think the result should be from this equation? In fact, most 
of us would say that the answer should be “seven”: 

1+2*3 = 7 

This is because, when we were young innocents at school, we were taught 
to perform any multiplications and divisions before considering any ad¬ 
ditions and subtractions. This order of operations is based on a concept 
known as the precedence of operators. The idea here is that some opera¬ 
tors are inherently more “powerful” than others. Generally speaking, the 
precedence of operators is taken to be as follows: 

0 Parenthesis (highest precedence) 

^ Exponents 

* / Multiplication and division 
+ - Addition and subtraction (lowest precedence) 

In the early days, some authorities stated that all of the multiplica¬ 
tions should be performed followed by all of the divisions. Furthermore, 
some folks decided that all of the additions should be performed fol¬ 
lowed by all of the subtractions. More recently, it is generally agreed that 
any multiplications and divisions should be performed from left to right; 
similarly, any additions and subtractions are now typically performed 
from left to right. 

There are two acronyms associated with this order of operations 
that are commonly employed as aids to memory: 
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PEMDAS Please Excuse My Dear Aunt Sally 

Parentheses 

Exponents 

Multiplication and Division 
Addition and Subtraction 

BEDMAS Big Elephants Destroy Mice And Snails 

Brackets (another term for parentheses) 

Exponents 

Division and Multiplication 
Addition and Subtraction 

The PEMDAS and BEDMAS rules may be applied recursively. For 
example, a pair of parentheses can contain a complex expression that it¬ 
self contains one or more pairs of parentheses containing their own ex¬ 
pressions, and so forth. 

The important thing to note is that all of this is just a convention. 
Nothing is written in stone. Deep in the mists of time, some people start¬ 
ed to adopt a certain way of doing things. As the years went by, more and 
more folks came to use the same convention because doing so made 
communication much easier. 


Direct Algebraic Logic 

The phrase direct algebraic logic (DAL) may be used to refer to a calcula¬ 
tor that is based on an infix notation scheme with limited understanding 
of the precedence of operators (this was true of early machines and re¬ 
mains the case for the majority of calculators to this day). The idea here 
is that the -t-, -, *, and / operators are treated as having equal precedence 
and are evaluated from left to right (that is, the order in which they are 
entered). In this case, the result from our original equation would be 
“nine” because the addition would be performed before the multiplica¬ 
tion: 


1 -h2*3 = 9 

The result is that anyone attempting to use a DAT-based calculator to 
solve equations of any complexity spends much of their time jotting in¬ 
termediate results down on a piece of paper. For example, consider how 
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a calculator based on a simple DAL infix notation would evaluate the fol¬ 
lowing equation: 

1 *2-h6/2 = 4 

In this case, the calculator would first perform 1*2 = 2, and then 
add the 6 to give 8, and then divide this value by 2 to give a final result of 
4. If we wished to perform this equation using the standard order of op¬ 
erations, we would be obliged to split it up as follows: 

1*2 = 2 

6/2 = 3 

2-h3 = 5 

In reality, most complex expressions simply cannot be expressed 
using a conventional infix notation without the use of parentheses. Thus, 
some electronic calculators were equipped with “(” and “)” keys, thereby 
allowing the above expression to be entered as follows: 

(l*2)-h(6/2) = 5 

In fact, parenthesis are often used by computer programmers to elimi¬ 
nate any possibility of confusion; for example, consider the following 
equation: 

(1 + 2) *3 = 9 

This is guaranteed to return a result of “nine” irrespective of the prece¬ 
dence rules being applied. 

Interestingly enough, some modern calculators go one step further 
by employing a concept known as advanced direct algebraic logic or ad¬ 
vanced DAL. In this case, the expression may be keyed in just the way you 
would write it on a piece of paper, with or without the use of parenthesis; 
for example: 

1 * 2 -t 6 / 2 [Enter] 

In this case, the input sequence is stored and no operations are performed 
until the [Enter] key (or possibly the equals “=” key) is pressed. At this 
point, the calculator analyzes the expression and evaluates it according to 
the standard PEMDAS/BEDMAS order of precedence, which means that 
such a machine would return the commonly expected result of “five.” 
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Polish and Reverse Polish Notations 


In the early 1920s, the Polish mathematician Jan Lukasiewicz 
(1878-1956) was working in the field of symbolic logic. At that time, he 
realized that placing operators in front of operands rather than between 
them rendered the use of parenthesis (brackets) unnecessary. 

As the operators preceded the operands, this was referred to as a 
prefix notation. Furthermore, due to the fact that non-Polish speakers 
found it difficult to wrap their tongues around his surname, 

Lukasiewicz’s technique became known as Polish notation (PN). (Had his 
family name been something like “Smith,” we would probably refer to 
this as Smith notation.) Although his work predated computers as we 
know them today, Lukasiewicz did note that his scheme was applicable 
to standard arithmetic operations. 

Some time later, in the mid-1950s, one of Australia’s first computer 
scientists, the philosopher Charles Leonard Hamblin (1822-1985), took 
Lukasiewicz’s ideas one step further. Working at the New South Wales 
University of Technology (NSWUT), Hamblin started to place the oper¬ 
ators afier the operands. For obvious reasons, this form of postfix nota¬ 
tion subsequently became known as reverse Polish notation (RPN). 

When the first electronic calculators were developed, the amount of 
memory available to them was somewhat limited and their computing 
power left a lot to be desired. Although RPN may appear confusing at 
first, it does offer several advantages: 

• It can be analyzed quickly and easily by a computer program. 

• It provides a very efficient way for a calculator to perform its 
computations. 

• It allows equations to be entered explicitly with no need for 
parentheses. 

• It allows technical users to perform complicated calculations 
using fewer keystrokes. 

As a user interface for calculation, RPN first appeared in the desk¬ 
top calculators manufactured by Hewlett Packard in the late 1960s, and 
later in their handheld scientific calculators in the early 1970s. In fact, 
many of Hewlett Packard’s scientific calculators continue to support 
RPN to this day (although users can now select between using the RPN 
and DAL input techniques). 
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Interactive laboratories 


OK, this is it, no more dilly-dallying or shilly-shallying because we’re 
poised to create our very own calculator. And so, without further ado, 
let’s race to complete the following interactive laboratories that you’ll 
find toward the back of this book: 


Lab 5a: Creating the Calculator Framework 
Lab 5b: Adding Some Low-Level Utility Routines 
Lab 5G: Creating a Decimal GETNUM (“get number”) 
Subroutine 

Lab 5d: Creating a Decimal DISPNUM (“display number”) 
Subroutine 

Lab 56: Implementing a Four-Function Integer Calculator 


Review 

In this chapter, we first considered some of the decisions we need to 
make as part of creating a calculator program. In particular, we intro¬ 
duced the concept of the usage model and then discussed the ideas 
behind the infix, prefix, and postfix notations. 

Next, we introduced the concepts of the order of operations and the 
precedence of operators. Based on these discussions, we noted the prob¬ 
lems associated with the direct algebraic logic (DAL) usage model and we 
then presented the ideas behind the Polish notation (PN) and reverse 
Polish notation (RPN) schemas. 

1) What do the acronyms PEMDAS and BEDMAS stand for? 

2) In the case of the equation “8 * 2 -I- 15 / 3 - 32 / 8,” what would be 
the result if this equation were to be evaluated using the standard 
PEMDAS/BEDMAS order of precedence? 

3) With regard to the previous question, what would be the result if the 
same equation were to be evaluated using a calculator based on a 
simple DAL usage model? 

4) Recreate the equation (8 * 2) -t- (15 / 3) - (32 / 8) in prefix notation. 

5) With regard to the previous question, list the minimum number of 
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keystrokes required to enter this equation into a PN-based calcula¬ 
tor (if there were such a beast). (Note: assume that you do not need 
to press the “Enter” key after an operator.) 

6 ) Recreate the equation (8 * 2) -t- (15 / 3) - (32 / 8) in postfix notation. 

7) With regard to the previous question, list the minimum number of 
keystrokes required to enter this equation into an RPN-based calcu¬ 
lator. (Note, assume that you do not need to press the “Enter” key 
after a math operator or after a number if that number is followed 
by a math operator.) 

8 ) With regard to the previous question, create a series of diagrams 
showing the state of the stack as you progress through the 
calculation. 

9) Recreate the equation {[(1-1-2) * 6] - 3} using a postfix (RPN) 
notation. 

10) Recreate the equation {1 -f- [2 * (6 - 3)]} using a postfix (RPN) 
notation. 
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If a man's wit be wandering, let him study 
the mathematics. 

Francis Bacon (1561-1626) in Essays (1625) 
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1 In this chapter we will ponder: 

C • Implementing additional functions 

• Binary and hexadecimal display and entry 

( • Reconfiguring the calculator’s front panel 

r. • Implementing structured (verbal) numbers 

C • Creating a binary floating-point calculator 

• Creating different flavors of BCD calculators 

• Creating code-coverage and profiler applications 

• Building a real DIY Calculator 

• And much, much more! 
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MORE FUNCTIONS AND EXPERIMENTS 


Introduction 


Yes, we know, this is the last chapter in the book. But turn that frown 
upside down into a smile, because there are still lots of experiments to 
perform, functions to create, additional programs to play with, and even 
the possibility of creating a real (physical) version of the DIY Calculator! 
And, of course, there are a lot of additional resources (with some special 
content for educators) on the CD-ROM accompanying this book and at 
the DIY Calculator website itself Plus, there are many other really inter¬ 
esting books to read. (These additional resources are discussed in more 
detail in Appendix D.) 


Implementing Additional 
Integer Functions 

With regard to the integer calculator we created in Chapter 5, the only 
math functions we’ve implemented thus far are -t-, -, *, /, and -t/- (that 
is: add, subtract, multiply, divide, and negate/change sign). However, the 
existing front panel contains a variety of other function buttons. Some of 
these, such as the reciprocal (1/x) and the trigonometric functions sin 
(pronounced “sign”), cos, and tan, make sense only in the context of a 
floating-point calculator as discussed later in this chapter. But there are 
other functions you could use to augment the capabilities of your integer 
calculator. We explore these below. 

Math functions 

Examples of some math functions that you might wish to consider im¬ 
plementing in the context of an integer calculator are as follows: 

• n! Calculate the factorial of the value currently being 

displayed (e.g., if the value currently being displayed is 5, 
pressing this button should perform the operation 5 X 4 X 
3x2x1 = 120). 

• x^ Calculate the square of the value currently being displayed 

(e.g., if the value currently being displayed is 5, pressing this 
button should perform the operation 5x5 = 25). 
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• Calculate the cube of the value currently being displayed 
(e.g., if the value currently being displayed is 5, pressing 
this button should perform the operation 5x5x5 = 125). 

• Mod Display the modulus (remainder) from an integer division 

(e.g., the result from the operation 14 Mod 3 will be 2). 

Binary and hexadecimal display and entry 

Just under the calculator’s main display area are three buttons marked 
Bin (binary), Dec (decimal), and Hex (hexadecimal). You could modify 
our display routines to use these buttons to convert whatever value is 
currently being displayed into the appropriate number system. For ex¬ 
ample, if the value on the main display is 42 in decimal, then clicking the 
Hex button should cause the appropriate LED (the light next to the but¬ 
ton) to light up; and it should also cause the display to present the equiv¬ 
alent hexadecimal value, which is 2A. Similarly, clicking the Bin button 
should cause that LED to light up and the display to show the equivalent 
binary value, which is 101010. 

As a further modification, you could augment the input routines so 
as to allow values to be entered in the selected number system. 

Reconfiguring the Calculator’s 
Front Panel 


One interesting feature associated with the calculator’s front panel is that 
you can modify the annotations on the current buttons and add new an¬ 
notations to the blank buttons. If you right-click on the Sin button, for 
example, you will be presented with the Configure Button Attributes di¬ 
alog window (Figure 6-1). 

The value in the Code field is the hexadecimal code that will be 
loaded into the front panel’s latch when you click this button. This value 
is shown with a gray background to reflect the fact that you cannot 
change it (at least not using this dialog). 

The text in the Annotation field reflects the characters that are to be 
displayed on the button. The pull-down list associated with the Color 
field allows you to select the color of the annotation text. Finally, the text 
in the Description field forms the tool tip that will appear if you leave the 
mouse cursor “hovering” over this button for a few seconds. 
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Apply 


Figure 6-1. Configuring button attributes. 


Any changes you make to a calculator button will take effect when 
you click the Apply button. Note, however, that these changes wiU only 
persist for the current session. If you wish these changes to become per¬ 
manent, you must use the Setup > Save New Buttons command before 
you terminate the current session (there is also a corresponding Setup > 
Restore Default Buttons command). 

Adding memory functions 

One very useful feature would be to augment your calculator with a 
“memory” in which you can store intermediate results from calculations. 
For example, you could reconfigure four of the blank buttons to perform 
the following functions: 

• MC Clear the memory to contain 0. 

• MS Store the value currently on display into the memory 

(overwrite any existing contents). 

• MR Recall the value in memory and display it on the main 

display (leave a copy of this value in the memory). 

• M-l- Add the value currently on display to the current contents 

of the memory. 

Adding logical functions 

If you decide to offer binary and hexadecimal number entry and display 
capabilities as discussed in the previous section, then you might also con- 
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template adding a selection of logical functions such as AND, OR, XOR, 
and INV to the front panel buttons. 

Adding other functions 

In the real world, different calculators provide different functions de¬ 
pending on their target audience. The advantage of the DIY Calculator is 
that you can configure its interface and program it to perform any func- 
tion(s) you desire. For example, you might decide to augment your cal¬ 
culator with a “%” button that can be used to easily calculate percent¬ 
ages. Or you could add a variety of statistics and probability functions 
(again, some of these functions will be of interest only in the context of a 
floating-point calculator as discussed later in this chapter). 


Implementing an Infix Notation 
Input Schema 

The calculator we implemented in Chapter 5 was based on the reverse 
Polish notation (RPN) usage model. As we discussed in that chapter, this 
is known as a postfix scheme because the operators follow the numbers; 
for example, in order to perform the calculation 6*2 + 3 using RPN, we 
would enter the following: 

3 [Enter] 6 [Enter] 2 [Enter] * -I- 

In this case, we don’t require the use of the equals “=” button be¬ 
cause the final result from the calculation will be displayed automatically. 
As an alternative, you could modify our input routines to support an 
infix usage model as discussed below. 

A simple infix model 

The simplest infix model, which may also be referred to as Direct 
Algebraic Logic (DAL), is to support operators between numbers as 
follows: 


6*24-3 = 15 


In this case, we do require the use of the equals “=” button to in¬ 
struct the calculator to display the final result. Note that when you are 
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implementing this type of scheme, you need to decide what to do if the 
user clicks on the same operator twice; for example: 

6*2++3=? 

Also, what should occur if the user were to click on two different opera¬ 
tors one after the other, as follows: 

6*2+*3=? 

As you will soon come to discover, implementing a robust input 
routine that can handle the user performing unexpected actions is a non¬ 
trivial task. 

Adding parentheses 

One problem with the simple infix model discussed above is that it eval¬ 
uates operations in the order in which they are entered; that is, from left- 
to-right. This means that if we were to enter the following, 

6 -t- 2 * 3 = 24 

the calculator would first add the 6 and the 2 to give 8, and then multiply 
this intermediate value by 3 to give a final result of 24. This is, of course, 
different from the way in which we would perform such a calculation by 
hand, in which case we would perform the multiplication before the ad¬ 
dition. One way to address this problem would be to augment our input 
routines to support the use of parentheses. This would allow us to explic¬ 
itly convey to the calculator what we are trying to achieve as follows: 

6-t-(2*3) = 12 

Initially you may decide to support only one set of parentheses at a time. 
Later on, you may choose to support nested parentheses; for example: 

6 + ((2*4)/(3-t 1)) = 8 

A more sophisticated infix model 

If you are really daring, you might contemplate offering a more sophisti¬ 
cated infix model, which may also be referred to as Advanced Direct Alge¬ 
braic Logic {Advanced DAL), that performs operations in exactly the same 
manner that you would do by hand; for example: 


6 -H 2 * 3 [Enter] 
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In this case, the calculator stores the input sequence and doesn’t perform 
any operations until it sees the Enter key, which is used to indicate the 
end of the equation. At this time, the calculator parses and analyzes the 
input sequence and performs the various operations using the conven¬ 
tional order of precedence discussed in Chapter 5 (for example, paren¬ 
theses, then multiplication and division, then addition and subtraction, 
etc.). 

Note that we might choose to use the Enter key and/or the equals 
“=” key to indicate the end of the equation (we show the Enter key here 
to emphasize the difference to our previous example). 

More Experiments with Integers 

Using Bigger Integers (of Fixed Size) 

When we created our basic math routines in the labs associated with 
Chapter 4, we decided to restrict ourselves to work with 2-byte (16-bit) 
values. But these can represent signed binary numbers only in the range 
-32,767 to -1-32,767 (remember that we are ignoring the most negative 
-32,768 value because we cannot represent its positive counterpart). 

One experiment you could perform would be to modify these rou¬ 
tines (along with the input and output routines we created in the labs as¬ 
sociated with Chapter 5) to work with bigger values. For example, you 
could elect to work with 3-byte (24-bit) values, which can be used to rep¬ 
resent numbers in the range -8,388,607 to -1-8,388,607; or you might opt 
for 4-byte (32-bit) values, which can be used to represent numbers in the 
range -2,147,483,647 to -t-2,147,483,647 (once again, we are ignoring the 
most negative values from these 3-byte and 4-byte schemes because we 
cannot represent their positive counterparts). 

Using arbitrarily (dynamically) sized integers 

The problem with choosing to work only with numbers of a fixed size 
(be it 2-byte, 3-byte, 4-byte, or more), is that, at some stage, we will al¬ 
most inevitably want to perform a calculation whose result exceeds our 
capability to represent it. One solution is to modify our input, output, 
and math routines to work with numbers of arbitrary size. 

For example, if we entered a value of 42^0 (that’s OOIOIOIO 2 in bina¬ 
ry) the input routine could determine that this would fit in a single byte. 



142 


MORE FUNCTIONS ANO EXPERIMENTS 


SO it could Store this (push it onto the stack) as a 2-byte value [Figure 
6-2(a)]. By comparison, if we input a value of l,957io, the input routine 
would recognize that this would fit in two bytes, so it would store it as a 
3-byte value [Figure 6-2(b)]. 

Theoretically, we could use this scheme to store numbers ranging 
from 1 to 255 bytes in size, where the latter can represent numbers so 
large it makes one’s eyes water to think about it. 

When we store this type of number, we would start by pushing its 
least-significant byte onto the stack and work our way up to the most- 
significant byte. Finally, we would push the extra “size” byte onto the 
stack. The reason for doing things this way is that, when we come to re¬ 
trieve one of these numbers, the first byte we pop off the stack will be the 
“size” byte, which will inform us as to how many additional bytes are 
used to form the actual number. 

Now, suppose we wish to perform an operation such as an addi¬ 
tion, in which case we would start by retrieving two numbers from the 
top of the stack. Let’s assume that one of these numbers is four bytes in 
size while the other is only two bytes. In this case, we would “pad” the 
smaller number with two bytes of Os to make the two values the same 
size before performing the addition. Of course, assuming both values to 
be positive, it may well be that the result will occupy five bytes. 

Similarly, in the case of a multiplication (and depending on the val¬ 
ues in question), the result may require more bytes than the two num¬ 
bers being multiplied (as a worst case, the number of bytes in the result 
will equal the sum of the bytes in the multiplier and multiplicand). By 
comparison, in the case of a division, the result may require fewer bytes 
than the dividend and the divisor. 

There are a number of things you have to think about when imple¬ 
menting this type of scheme, as you will doubtless discover for yourself 
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Figure 6-2. Dynamically sized integers. 
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Size = 1 1-byte value 
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Figure 6-3. The MS bit is always the sign bit. 


But just to get you off to the right start, let’s suppose that you enter a 
value of -t-127i0) which will fit in a single byte, as shown in Figure 6-3(a). 

Now, assume that we add 1 to this value, resulting in -l-128io- In this 
case, the result will have to be stored in a 2-byte field, as shown in Figure 
6-3(b), otherwise we would have to assume that this value represented 
-128io- Thus, we need to enforce a rule that the most-significant bit of 
the most-significant data byte is always considered to be the sign bit for 
this value. 


Implementing Structured 
(Verbal) Numbers 

When entering values into a calculator, we often wish to enter a quantity 
of hundreds or thousands; for example, 700 or 8000. This type of thing is 
very common when performing financial calculations, so one occasional¬ 
ly runs across a calculator boasting a couple of extra buttons with “00” 
and “000” annotations (Figure 6-4). 
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Figure 6-4. Calculator with “00” and “000” buttons. 
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The idea here is that if you press the “8” button followed by the 
“000” button, for example, the calculator will immediately display 
“8000.” This can be very useful, and it’s possible to extend this scheme in 
interesting directions. As one example, calculator enthusiast James Redin 
holds U.S. Patent 5,623,433 on what he refers to as Structured Numbers 
or Verbal Numerals. James points out that when we look at a date like 
2005, we don’t conceptualize it as “two-zero-zero-five,” but instead, we 
think of it the same way we would verbalize it, which is “two thousand 
and five.” Similarly, when we look at a number such as 2,007,000, we 
think of this as “two million, seven thousand.” Entering this number the 
normal way would require seven keystrokes. James proposes augmenting 
standard Western/English calculator keypads with three extra keys bear¬ 
ing the annotations “H” (hundred), “T” (thousand), and “M” (million), 
as shown in Figure 6-5. 

In this case, we could enter the 4-key sequence “2” [M] “7” [T], 
which would result in the following progression appearing on the 
calculator’s display: 


Keystrokes Output Display 


[2] 

2 

[M] 

2,000,000 

[7] 

2,000,007 

[T] 

2,007,000 


The use of structured numbers in this example means that we re¬ 
quire approximately half the keystrokes as compared to entering the 
same value on a standard keypad. Also, the use of structured numbers 
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Figure 6-5. Calculator with H, T, and M buttons. 
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saves us from the mental gymnastics associated with figuring out how 
many zeros to use and where they should be included. 

The point is that you could reconfigure some of the DIY Calculator’s 
buttons to represent these additional keys, and then modify our input 
routines to handle this structured number entry format. (More detailed 
descriptions of verbal numbers and structured number entry techniques 
are provided in the Xnumbers folder on the CD-ROM accompanying this 
book; see Appendix D for more details on these additional resources.) 


The reason we used the “Western/English” qualifier above is that different languages use different 
word structures to define numbers. For example, in the same way that we have a special word for 1000 (“thou¬ 
sand”), the Japanese have a special word for 10,000, which we would have to verbalize as “ten thousand.” 


Creating a Binary Floating-Point 
Calculator 


Up until this point, we’ve only considered working with integer values. In 
reality, of course, this is very limiting, because it means that we can’t rep¬ 
resent real numbers like 3.142. If you visit our website at 
www.DIYCalculator.com, you will find some additional materials in 
which we discuss the concepts of floating-point representations and de¬ 
fine our own simple binary floating-point format. A very interesting pro¬ 
ject would be to create input, output, and math routines that work with 
this floating-point format. 

Once you have created floating-point routines to perform the fun¬ 
damental operations (+, -, /, and +/-), you could start adding func¬ 

tions like 1/x (reciprocal). You may also decide to program the Pi button 
such that pressing it automatically displays the value of tt (to the preci¬ 
sion supported by our floating-point format) and pushes a copy of this 
value onto the top of the stack. Later, you might start experimenting 
with more complex functions such as Rx (square root), and eventually 
work your way up to the trigonometric functions sin, cos, and tan. 

Creating a BCD Calculator 

The term binary coded decimal (BCD) refers to a technique for storing 
and manipulating numbers inside a computer in which each decimal 
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digit is represented as a 4-bit binary value. Our website at www.DIYCal- 
culator.com features some additional materials in which we introduce 
the concepts associated with BCD representations. As discussed on the 
website, there are some advantages to using BCD; thus, it may not sur¬ 
prise you to hear that another interesting project would be to create in¬ 
put, output, and math routines that work in BCD. 

Fixed-precision integer BCD 

As a starting point, you might choose to create a fixed-precision integer 
BCD calculator. If you decide that each number will occupy a 4-byte 
field, where the most significant nybble represents the sign, for example, 
then you will be able to represent numbers in the range -9,999,999 to 
-t-9,999,999 (assuming a sign-magnitude format for the purpose of these 
discussions). 

Arbitrary-precision integer BCD 

Alternatively, you might elect to work with arbitrary (dynamically) sized 
integer BCD values, where the first byte could be used to specify the 
number of BCD digits in the number. 

Structured (verbal) entry and BCD 

Irrespective of whether you opt to use fixed or variable precision integer 
BCD representations, you might decide to support the structured (ver¬ 
bal) number entry techniques mentioned earlier in this chapter. 

Fixed-precision fixed-point BCD 

As yet another alternative, you could determine to work with a fixed-pre¬ 
cision, fixed-point BCD format, in which each number occupied a 7-byte 
field, for example, with the digits in the least-significant three bytes being 
considered to be to the right of the decimal point. In this case, you could 
represent numbers in the range -9,999,999.999999 to +9,999,999.999999 
(again, we’re assuming a sign-magnitude format for the purpose of these 
discussions). 

Arbitrary-precision fixed-point BCD 

Of course, you might prefer to work with arbitrary (dynamically) sized 
fixed-point BCD values. In this case, the most-significant nybble of the 
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“size” byte could be used to define the number of digits (from 0 to 15) to 
the left of the decimal point (excluding the sign nybble). Similarly, the 
least-significant nybble of the “size” byte could be used to define the 
number of digits (from 0 to 15) to the right of the decimal point. In this 
case, a number such as -1-12345.67 would be represented as shown in 
Figure 6-6. 

Floating-point BCD 

Last, but certainly not least, you could throw caution to the winds and 
implement a floating-point BCD calculator. Apart from anything else, if 
you created a similar format to that used for the binary floating-point 
implementation presented on the DIY Calculator website (7 digits for the 
exponent and 16 for the mantissa), then it would be interesting to com¬ 
pare these two implementations in terms of code size (memory utiliza¬ 
tion) and performance (execution speed). 

Of course, the performance metric will be a little tricky. Computers 
now go so fast that it would be difficult to compare the speed of two 
functions like the binary and BCD implementations of a floating-point 
multiply routine using a stopwatch. What we need is some form of pro¬ 
filer application... 


Creating Code-Coverage and 
Profiler Applications 

Good grief! What a coincidence! We were just talking about this in the 
previous section! Although we haven’t discussed this aspect of things 
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Figure 6-6. A dynamically sized fixed-point BCD representation. 
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thus far, the DIY Calculator has been designed with “hooks” that allow 
you to capture interesting data while you are running a program. For ex¬ 
ample, it can be used to record the number of times each instruction was 
executed (and the number of times each data location was accessed) over 
the course of some defined period such as entering and exiting a particu¬ 
lar subroutine. 

All of this data can be output in the form of an ASCII text file. Also 
available is a reference file that details the number of virtual clock cycles^ 
required to execute each instruction in each addressing mode (in the case 
of the conditional jump instructions, there are two values depending on 
whether the test passes or fails). 

Our thought was that someone (maybe us, maybe you), could write 
a program that can analyze this data and present a graphical representa¬ 
tion of the code coverage; that is: 

• Which instructions were executed? 

• Which instructions weren’t executed? 

• Which data locations were accessed? 

• Which data locations were left untouched? 

It would also be possible to create a profiler that graphically shows which 
areas of a program (or subroutine) were used the most and which the 
least. For example, if you see a “hot spot” that is consuming a large pro¬ 
portion of the processing time, a little judicious tweaking of that portion 
of the code may yield significant performance improvements for the 
program as a whole. 

The ways in which you can access this data, the format of the files, 
and some thoughts on the techniques one might use to process the data 
and present the results are discussed in more detail on the DIY Calcula¬ 
tor website at www.DIYCalculator.com. 


Building a Real DIY Calculator 

The virtual version of the DIY Calculator featured in this book provides 
a fantastic tool for learning about computers and calculators. However, 

^ The Official DIY Calculator Data Book (which, as discussed in Appendix D, is included on 
the CD-ROM accompanying this book) describes the internal architecture of the calcula¬ 
tor’s CPU, including a breakdown of the clock cycles required to execute each instruction. 
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there is something strangely satisfying about having access to a real ma¬ 
chine, so we’ve been pondering the idea of creating a real, physical ver¬ 
sion of the DIY Calculator. 

As discussed in Appendix D, the CD-ROM accompanying this 
book includes a data book that describes the inner architecture of the 
calculator’s central processing unit (CPU) in excruciating detail. This data 
book provides more than enough information to create a physical imple¬ 
mentation of the calculator, but how should we go about tackling this? 

Using discrete devices 

One approach would be to use off-the-shelf integrated circuits (ICs), 
which are affectionally known as silicon chips. In the case of simple 
(“jelly-bean”) devices, for example, one chip may provide four 2-input 
AND gates, another might provide six inverters, and another may boast 
four register (memory) elements. 

In addition to the CPU, we would also have to add memory devices 
in which to store programs and input/output (I/O) port devices with 
which to communicate with the outside world. Then we would have to 
add the calculator buttons and display device. And we would also have to 
implement some way for the calculator to “talk” to our personal com¬ 
puter (PC) such that we could download machine-code programs creat¬ 
ed on the main computer into the physical calculator. 

It would certainly be interesting to design and build a system using 
these basic devices, but it would also be time-consuming, expensive, and 
prone to error (having said this, the authors have actually considered 
building a relay-based version of the calculator). 

Using an off-the-shelf 
microprocessor/microcontroller 

Another technique would be to take a simple off-the-shelf microprocessor 
ipiP) or microcontroller {pcC) and create a small circuit board featuring 
this device, some memory, some I/O ports, some buttons (to represent 
the calculator buttons), and a display device such as a small liquid crystal 
display (LCD). 

Once again, we would also have to implement some way for the 
physical calculator and main computer to communicate with each 
other in order to be able to download machine-code programs into the 
calculator. 
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There are now two ways in which we could proceed: 

1) We could create a special cross-assembler to run on the main com¬ 
puter. This cross-assembler could be used to take source-code pro¬ 
grams written in the DIY Calculator’s assembly language and gener¬ 
ate two different types of machine-code files: one using the DIY 
Calculator’s instruction set and opcodes; the other using the real 
p.P/p.C’s instruction set and opcodes. This would allow us to create 
and debug our programs in the virtual world as usual, and to then 
download the p.P/p.C version into the physical calculator. 

2) Alternatively, we could use an appropriate assembler to write a spe¬ 
cial “interpreter” program to run on the p.P/p.C. We would then cre¬ 
ate and debug our programs in the virtual world as usual. Once the 
DIY Calculator’s machine-code version of the program was working 
to our satisfaction, we could download it into the physical calculator. 
The interpreter program would now be used to interpret our DIY 
Calculator program on an instruction-by-instruction basis. 

Using a field-programmable gate array (FPGA) 

We’ve saved the best for last (hurray!). As its name suggests, a field- 
programmable gate array (FPGA) is a silicon chip whose function can be 
configured (programmed) by the user “in the field.” Furthermore, some 
FPGA types can be reprogrammed with new configurations over and 
over again. 

Depending on the device in question, an FPGA can contain the 
equivalent of a few hundred thousand logic gates to tens of millions of 
gates. Also, in addition to this raw logic, the FPGA can contain other ele¬ 
ments, such as blocks of memory. 

As we know, the virtual DIY Calculator consists of a CPU, some 
memory, some I/O ports, some buttons, and a display device. The idea 
here is to program an FPGA to emulate the functions of the CPU, mem¬ 
ory, and I/O ports. We would also create a small circuit board containing 
this device along with the calculator’s buttons and displays. The FPGA 
could also be used to implement a communications interface, such as a 
serial I/O port or a USB port, that the physical calculator could use to 
“talk” with the main computer. 

When it comes to creating FPGA-based designs, there are a number 
of different tools and vendors available. For this type of project, however. 
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the design tools from Altium Ltd. (www.altium.com) are incredibly well- 
suited to the task. First and foremost is Protel 2004, which is a complete 
circuit board design solution that includes hierarchical schematic (circuit 
diagram) capture, mixed-signal simulation, signal-integrity analysis, and 
rules-driven board layout. 

This means that we could use Protel 2004 to design the physical cal¬ 
culator’s circuit board. However, in addition to all of its board-level ca¬ 
pabilities, the reason Protel 2004 is of interest to us here is that it also 
features a fully integrated FPGA design environment. The system comes 
equipped with libraries of functions ranging from simple gates, to multi¬ 
bit registers, adders, counters, and memory blocks. Also included are 
communications blocks such as serial I/O and USB ports. Each of these 
logical functions comes equipped with a corresponding schematic sym¬ 
bol. This means that we could capture the DIY Calculator’s CPU, memo¬ 
ry, and I/O ports as a schematic of functional blocks. The system can 
then be used to generate the configuration file used to program the real 
FPGA device. 

Alternatively, if we wished to base our physical implementation on 
an off-the-shelf microprocessor (such as a PIC, for example) as discussed 
in the previous section, then Altium also offers a product called Nexar 
2004. As with Protel 2004, this little rapscallion allows you to capture an 
FPGA design as a block-level schematic; but in addition to the regular 
logical function blocks discussed above, it also allows you to include one 
or more microprocessor blocks in your design. Each processor comes 
equipped with appropriate compilers and assemblers, and also a com¬ 
plete source-level debugging environment. 

Last, but certainly not least, Altium has an FPGA development 
board, called the NanoBoard, that works with both Protel 2004 and 
Nexar 2004. When you connect the NanoBoard to your main computer, 
you can download your FPGA designs directly into an on-board FPGA 
and then run and debug these designs in real time. One cool thing about 
the NanoBoard is that it supports multiple target devices in the form of 
swappable FPGA daughter boards, which means you aren’t tied to a par¬ 
ticular FPGA vendor or device. 

Further reading 

There are several points relating to the creation of a physical version of 
the DIY Calculator that could be a little tricky unless one thinks them 
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through beforehand. But we don’t want to wander off into the weeds 
here, so if you are interested in learning more, visit our website at 
www.DIYCalculator.com. 

Also, multimedia presentations on Protel 2004, Nexar 2004, the 
NanoBoard, and associated evaluation kits are provided in the Altium 
folder on the CD-ROM accompanying this book; see Appendix D for 
more details on these additional resources. 


Sharing Your Work With Others 

If you do create something interesting as discussed below, then please 
feel free to send it to us (with appropriate documentation) for inclusion 
on our website so that others can peruse and ponder your masterpiece. 
We will, of course, give you full credit for your work (check out the notes 
at www.DIYCalculator.com for more details). 

Subroutines 

For example, let’s suppose you are looking at a subroutine on our web¬ 
site (or a routine presented in this book) and you say to yourself: “I can 
do the same thing using half of the memory (but it won’t go as fast),” or 
“I can do the same thing twice as quickly (but it will use more memo¬ 
ry),” or, if you’re really good, “I can do the same thing using half of the 
memory and make it go twice as fast!” 

Well, “talk is cheap,” as they say, and “the proof of the pudding is 
in the eating.” If you do create an interesting version of a subroutine (in¬ 
teger, floating-point, or BCD-based), then please feel free to share it with 
us and we’ll make it availabe to other readers via the website. 


If you reconfigure the buttons on the calculator’s front panel as part of your project, then you should 
also send us a copy of the newbuttons.ini file that you’ll find in the C:\DIY CalculatoAConfig folder. 


Entire calculators 

If you are really brave, you may go beyond creating a simple subroutine, 
and instead implement an entire calculator: for example, your version of 
a BCD-based floating-point calculator. Once again, please feel free to 
share anything like this with us for inclusion on our website. 
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Design files for physical versions of the 
DIY Calculator 

With regard to a physical implementation of the DIY Calculator, it 
should be noted that the CPU design documented in the data book on 
the CD-ROM was created so as to be understandable. To put this anoth¬ 
er way, the original design is not as efficient as one might hope. 

Our thoughts are that it would be a good idea to first create the de¬ 
sign cycle-for-cycle as documented in the data book. Once this first im¬ 
plementation is working, it would be interesting to explore alternative 
architectures that can execute the same machine-code files in a more 
efficient manner. 

As usual, if you do anything like this, we would love to hear about it 
and, if you wish, we will post copies of your design notes and design files 
on our website for the delectation and delight of other DIY Calculator 
enthusiasts. 
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Lab 


Objective: To introduce the DIY Calculator’s assembly language and 

assembler. Also to create, load, and run a simple program 
that clears the calculator’s main display 
Duration: Approximately 25 minutes. 


The Memory Map 

Before we commence this lab, we need to be aware of the way in which 
a central processing unit {CPU) perceives the external world, which is as 
a series of memory locations. Our CPU’s 16-bit address bus can be 
used to point to 2^® = 65,536 unique locations, which would be num¬ 
bered from 0 to 65,535 if we were counting in decimal (remember 
that we typically start counting things from 0 when working with 
computers). 

As was noted in Chapter 1, however, the decimal numbering sys¬ 
tem is not particularly convenient for our purposes. Thus, we prefer to 
number these locations from $0000 to $FFFF using the hexadecimal 
numbering system (where “$” characters are used to indicate hexadeci¬ 
mal values). 

A common method for representing the way in which the comput¬ 
er’s memory is allocated and organized is by means of a diagram called a 
memory map (Figure L2-1). 

In the case of our virtual computer system, addresses $0000 
through $3FFF are occupied by read-only memory (ROM), whereas 
addresses $4000 through $EFFF are occupied by random access memory 
{RAM). 

If this were a real calculator, the ROM would contain the prede¬ 
fined routines used to read numbers and function keys from the key- 
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$0000 $3FFF SFOOO $F03F 



ROM 


RAM 


Input and output ports 


Figure L2-1. The memory map. 


pad, perform arithmetic operations on the numbers, and display the 
results. Thus, when the calculator was first powered up, a power-on re¬ 
set signal would cause the CPU to start executing the program in the 
ROM. This program would first clear the calculator’s display, initialize 
anything needing to be initialized, and then wait for the user to start 
pressing some buttons. In such a scenario, the RAM would be used 
primarily to store temporary data, intermediate values, and pending 
operations. 

With regard to our virtual calculator, however, we don’t have any 
predefined math routines stored in the ROM. During the course of this 
book we are going to create these routines ourselves, and any programs 
we generate will be loaded directly into the RAM. Having said this, it will 
make some things easier to describe and understand if we assume that 
the ROM contains a simple monitor program that performs a few low- 
level housekeeping tasks. 

Toward the top of the memory map are the input and output 
(I/O) ports that the CPU uses to communicate with the outside world 
in the form of the calculator’s front panel. In fact, the CPU regards 
these I/O port addresses as standard memory locations and doesn’t re¬ 
alize we’re using them for our own cunning purposes. Addresses $F000 
through $F01F are occupied by a set of 32 input ports (of which the 
front panel uses only one port at address $F011), whereas addresses 
$F020 through $F03F are occupied by a set of 32 output ports (of 
which the front panel employs only two ports at addresses $F031 and 
$F032). Finally, addresses $F040 through $FFFF are unused in this im¬ 
plementation (Table L2-1). 
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TABLE L2-1. Summary of memory allocation 


Addresses 


Function 

$0000 to 

$3FFF 

ROM 

$4000 to 

$EFFF 

RAM 

$F000 to 

$F01F 

Input ports 

$F020 to 

$F03F 

Output ports 

$F040 to 

$FFFF 

Unused 


The Accumulator (ACC) 

One other point of which we need to be aware before plunging headfirst 
into the fray is that, among other things, our CPU contains an 8-bit reg¬ 
ister called the accumulator {ACC). (The term “register” refers to a group 
of memory elements, each of which can store a single binary digit.) As its 
name implies, the accumulator is where the CPU gathers, or accumu¬ 
lates, intermediate results (Figure L2-2). 

Observe the way we indicated the size of the accumulator as being 
[7:0] in this figure. This is referred to as vector notation. The accumulator 
comprises eight bits, and these bits are numbered from 0 to 7, with bit 0 
being the least-significant bit (LSB) on the right-hand side, and bit 7 be¬ 
ing the most-significant bit (MSB) on the left-hand side. 

The reason for numbering these bits from 0 to 7 is discussed in 



(a) The accumulator is an 
8-bit register in the CPU 


(b) Accumulator bit¬ 
numbering scheme 


Figure L2-2. The accumulator (ACC). 
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Chapter 4. For our purposes here, we need only note that we could give 
each of these bits individual names such as acc7, acc6, acc5, acc4, acc3, 
acc2, accl, and accO, where this would be referred to as a scalar notation. 
However, suppose we wish to associate a binary value of %01010011 
with bits 7 through 0, respectively. Using a scalar notation, we would 
have to say something like “acc7 = 0, acc6 = 1, acc5 = 0, acc4=l . . This 
is laborious and time-consuming to write, and nonintuitive to under¬ 
stand. A better solution is to use a vector notation, in which case we 
could simply say “acc[7,6,5,4,3,2,l,0] = %01010011,” and we can abbre¬ 
viate this to “acc[7:0] = %01010011,” where the colon character is 
used to indicate a range. 

The ways in which we can modify and use the contents of the accu¬ 
mulator will become apparent as we progress. Suffice it to say that: 

• The CPU can be instructed to load (read) a byte of data from any 
external memory location (or input port) into the accumulator. 
This involves taking a copy of the data in the memory; the con¬ 
tents of the memory at that location remain undisturbed. 

• The CPU can be instructed to perform a variety of arithmetic 
and logical operations on the data in the accumulator. 

• The CPU can be instructed to store (write) the contents of the ac¬ 
cumulator into a memory location (or output port). This over¬ 
writes any existing contents in that memory location, but leaves 
the contents of the accumulator undisturbed. 

The Program We’re About to Create 

The program we’re about to create is very simple and contains just three 
instructions (Figure L2-3). The first instruction loads a value of $10 into 
the accumulator (the significance of this value will become apparent 
shortly). The second instruction writes the contents of the accumulator 
to the output port that drives the calculator front panel’s main display 
area. And the third instruction directs the CPU to jump to address $0000 
(this is the first location in our ROM, which we may assume contains a 
low-level monitor routine that will cause the CPU to automatically 
terminate the program and return the system to its reset mode). 

To the left of Figure L2-3 is a special diagram called a flowchart, 
which is used to illustrate the sequence of operations. The rectangular 
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Memory 

Address 


Memory 

Contents 


$4000 

$4001 


$90 

$10 


$90 = Load the contents of the following 
byte ($10) into the accumulator. 


$4002 

$4003 

$4004 

$4005 

$4006 

$4007 


$99 

$F0 


$C1 

$ 00 ” 

$00 


$99 = Store the contents of the accumulator into 
the address specified by the following two bytes 
($F0and $31 = $F031). 


$C1 = Jump to the address specified by the 
following two bytes ($00 and $00 = $0000). 


Figure L2-3. Flowchart for a program to clear the main display. 


boxes in the flowchart represent the actions to be performed. To the 
right of each action box is a representation of the equivalent machine 
code (the raw numerical values) that must be placed into our virtual 
computer’s memory. This numerical representation is called “machine 
code” because this is the form that is understood and executed by the 
computer (machine). 

The first instruction is located at address $4000, which is the first 
location in the RAM. All of our programs wiU commence at this location, 
because this is the address that our monitor program will automatically 
jump to when we press the Run button on the front panel. 

The $90, $99, and $C1 values are known as operation codes (op¬ 
codes for short) and are part of the CPUs instruction set (see also the 
More! More! section at the end of this lab). The $90 opcode at address 
$4000 instructs the CPU to load the following byte ($10) into the accu¬ 
mulator. This form of instruction is said to use the immediate addressing 
mode, because the data associated with the instruction is located immedi¬ 
ately after the opcode (the data is referred to as the operand). The reason 
we wish to load $10 into the accumulator is that this is a special code to 
clear the calculator’s main display (the rationale for this will become ap¬ 
parent in Lab 2c). 

The $99 opcode at address $4002 directs the CPU to store a copy of 
the contents of the accumulator into the location pointed to by the fol¬ 
lowing two bytes ($F0 and $31 = $F031). This form of instruction is said 
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to use the absolute addressing mode, because the two-byte operand fol¬ 
lowing the opcode contains a specific (absolute) address. What the CPU 
doesn’t know is that address $F031 doesn’t actually point to a location in 
the memory, but instead points to the output port that drives the front 
panel’s main display (this port is discussed in more detail in Lab 2c). 

Finally, the $C1 opcode at address $4005 tells the CPU to perform 
an unconditional jump to the location pointed to by the following two 
bytes ($00 and $00 = $0000). This address is the first instruction in the 
monitor program, which resides in our virtual computer’s ROM and 
which is of no great concern to us here. All we really need to know is 
that, in the case of our virtual system, a jump to address $0000 will 
cause the program to automatically terminate and the CPU to enter its 
reset mode. 

Entering and Assembling a Program 

If we wished, we could write all of our programs directly in machine 
code and then manually insert them into the system’s memory, one byte 
at a time. However, this approach would be extremely time-consuming, 
excruciatingly boring, and terribly error-prone to say the least. A vastly 
more preferable technique is to describe our programs at a higher level of 
abstraction, and to then use a special computer program to automatically 
translate these programs into their machine code equivalents. The first 
step up the evolutionary ladder for programming languages is called 
assembly language. Once we’ve captured a program in assembly 
language, we use a special program called an assembler to convert it into 
machine code. 

If you haven’t already done so, install your DIY Calculator now as 
discussed in Appendix A. Once you’ve performed this installation, use 
the Start > Programs > DIY Calculator > DIY Calculator command (or 
double-click the DIY Calculator icon on your desktop) to invoke the lit¬ 
tle rascal (Figure L2-4). 

In the middle of the main DIY Calculator window is the calculator 
front panel (the “calculator” or “front panel” for short), which can be 
used to feed data to, display results from, and control the calculator 
(Figure L2-5). But in order for this front panel to do anything useful we 
need a program, and creating such a program (even a small one) is, of 
course, the purpose of this lab. 
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Figure L2-4. The main DIY Calculator window. 
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Figure L2-5. The calculator front panel. 
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The assembler is an independent executable application (program) that is launched from within the 
main DIY Calculator interface. When you click on any part of the DIY Calculator interface after you have 
launched the assembler, then the main interface will “come forward” and may completely obscure the assem¬ 
bler. Should this occur, you can click the Assembler / Editor item in the main Windows® taskbar to bring this 
application to the foreground. 


Use the Tools > Assembler pull-down menu in the main window 
(or click the appropriate icon on the tool bar) to invoke the assembler 
(Figure L2-6). This tool serves two purposes. First, it acts as an editor 
that allows us to capture programs in our assembly language (this is 
called the source program and, when saved out into a file, it may be re¬ 
ferred to as the source file). Second, the interface can be used to call the 
assembler function, which assembles our source code into equivalent 
machine code. Make sure that the cursor is flashing in the assembler’s 
working area, and then enter the following program in our assembly 
language: 


ORG 

$4000 

# 

Set program's origin to address $4000 

LDA 

$10 

# 

Load accumulator with clear code 

STA 

[$F031] 

# 

Store accumulator to address $F031 

JMP 

[$0000] 

# 

Jump to address $0000 

END 


# 

This is the end of the program 






Title bar 
Menu bar 

Tool bar 


Working area 


Status and 
message bar 


Figure L2-6. The assembler. 
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Convention dictates that directive staements like .org and .end are prefixed by period (full-stop) 


characters. There really is no inherent reason why this should be so, but it does provide a visual cue to the 
reader, thereby making programs slightly easier to understand. Also, these periods can be quickly 
recognized by the assembler, which may help to make it slightly more efficient. 


Observe the . ORG and . end statements. These are known pseudoin¬ 
structions or directives (because they “direct” the assembler). The . ORG is 
used to specify the start address or origin of the program (address $4000 
in this case), whereas the . end informs the assembler when it reaches the 
end of the program. 

Also note that anything to the right of a hash “#” character (also 
known as a number sign, pound sign, or sharp) is considered to be a com¬ 
ment. Comments may occur anywhere on a source line and are ignored 
by the assembler. (It’s very important to make use of meaningful com¬ 
ments. Just because you know what you intend your program to do to¬ 
day does not mean you will understand it six months—and six thousand 
lines of code—later!) 

Now consider the lda $10 statement, where lda is a mnemonic 
meaning ‘load the accumulator.” This statement instructs the CPU to 
load the value $10 into the accumulator. Once again, the reason we wish 
to load $10 into the accumulator is that this is a special code to clear the 
calculator’s main display. 

Contrast the immediate addressing mode used by the lda with the 
absolute mode employed by the next instruction, the STA [ $e03 1 ], 
which instructs the CPU to store the contents of the accumulator to the 
location at address $F031. (Remember that we’re tricking the CPU in 
this case because, instead of pointing at a memory location, address 
$F031 actually points to the output port driving the calculator’s main 
display.) As we see, our assembly language uses square brackets [ and ] 
to imply that we’re talking about the contents of a memory location. The 
JMP [$0000] instruction also uses the absolute addressing mode to in¬ 
struct the CPU to perform an unconditional jump to address $0000. 
Jumping to this address terminates the program and returns control to 
our monitor program, which is stored in the calculator’s ROM. 

Once you’ve entered this program, use the assembler’s File > Save 
As command to save it to a file called lab2a.asm. (By default, the File > 
Save As dialog should be pointing to the C:\DIY Calculator\Work folder; 
if not, set the context to this folder before clicking the Save button.) 
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Now comes the exciting part where you assemble your program, 
which you do by selecting the File > Assemble pull-down menu in the as¬ 
sembler’s menu bar (or by clicking the appropriate icon on the assembler’s 
tool bar). Assuming you haven’t made any errors, you’ll receive a message 
along the lines of‘‘File assembled successfully' in the assembler’s status bar; 
otherwise you’ll have to debug any mistakes and try again (Figure L2-7). 

In addition to a number of other actions, the assembler has just 
created a file called lab2a.ram, which contains the machine-code equiva¬ 
lent of your program. Once you’ve successfully assembled your program, 
exit the assembler to make room on your screen. 


Creating anything other than a very simple program is usually a very iterative process; the assembler 
locates errors and you fix them. Some assemblers will report a whole slew of errors together, but ours identifies 
them one at a time (this latter technique is easier for beginners). 

The "^.ram output file is only generated if the assembler doesn’t detect any errors. This means that if 
you make a change to a program and try to assemble it, the old *.ram file won’t be overwritten until you’ve 
identified and fixed any errors. 


Loading and Running a Program 

First click the front panel’s On/Off button to power-up the calculator. 
Observe that the calculator’s main display area fills up with charac¬ 
ters, which indicate that it’s in an uninitialized state. Similarly, the six lit¬ 
tle lights next to the Bin, Dec, and Hex (and related) buttons just under 
the main display all glow red to indicate that they also are in uninitialized 
states. 

Now use the main DIY Calculator window’s Memory > Load RAM 
pull-down menu to invoke a dialog offering a list of the programs that 
are currently available. Select (click on) the lab2a.ram file you just creat¬ 
ed and then click the dialog window’s Load button to load the contents 
of this file into the calculator’s memory. 

Now click the front panel’s Run button to execute your program 
(the monitor program causes the CPU to automatically start with what¬ 
ever instruction it finds at address $4000). As we already know, this pro¬ 
gram loads the accumulator with the $10 clear code, writes this code to 
the output port driving the calculator’s main display (thereby clearing 
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Figure L2-7. Using the assembler to create a machine code (.ram) file. 


the display), and then jumps to address $0000, which returns the CPU to 
its reset mode (you will see this mode indicated in the main DIY Calcula¬ 
tor window’s status bar). 

Congratulations! You’ve successfully written, assembled, loaded, 
and executed your first program. Now that wasn’t too bad, was it? 

More! Morel 

These labs have been constructed in such a way that you will be intro¬ 
duced to appropriate opcodes, addressing modes, and assembly language 
constructs on an “as you need them” basis (similarly for tools like the As¬ 
sembler, Memory Walker, and CPU Register display). Also, you’ll find a 
more detailed summary of the various addressing modes in Appendix B 
and a summary of the instruction set, including a table showing the vari¬ 
ous addressing modes supported by each instruction, in Appendix C. 

For your delectation and delight (or if you just want to plunge in 
deeper), you will discover a wealth of additional information on the in¬ 
struction set and assembly language on the CD-ROM accompanying this 
copy of How Computers Do Math. See the Additional Resources discus¬ 
sions in Appendix D for more details. 























Lab 

2b 


Objective: To use constant labels and .EQU directives to make 

programs easier to read and understand. 

Duration: Approximately 20 minutes. 

Making Program Listings More 
User-Friendiy 

If you haven’t already done so, launch the main DIY Calculator and then 
use the Tools > Assembler pull-down menu (or click the appropriate 
icon on the main window’s tool bar) to invoke the assembler. 

Now use the assembler’s File > Open command to access the 
labia, asm file you created in the previous lab, and then use the File > 
Save As command to rename and save this file as lablb.asm. As you will 
recall, although our original program performed the task for which it 
was intended, its appearance was not particularly user-friendly: 

.ORG $4000 # Set program's origin to address $4000 

LDA $10 # Load accumulator with clear code 

STA [$F031] # Store accumulator to address $F031 

JMP [$0000] # Jump to address $0000 

.END # This is the end of the program 

Using Constant Labels 

Even if we happen to know that $10 is the calculator’s clear code and 
$F031 is the address of the output port driving the calculator’s main dis¬ 
play, this program is still somewhat difficult to read. One way to alleviate 
this is to replace some of the numeric values with user-friendly labels. 
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Constant Labels and 
.EQU Directives 
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These labels can be called anything we want so long as they conform to 
the rules laid down at the end of this lab. For example, consider two 
slight modifications to our program as shown below (the changes are 
highlighted in gray): 


.EQU 

$10 

# 

Special code to clear the main display 

.ORG 

$4000 

# 

Set program's origin to address $4000 

LDA 

CLRCODE 

# 

Load accumulator with clear code 

STA 

[$F031] 

# 

Store accumulator to address $F031 

JMP 

[$0000] 

# 

Jump to address $0000 

.END 


# 

This is the end of the program 


The first modification is to declare a constant label called clrcode, and 
to use an . EQU directive (which stands for “equates to”) to assign a value 
of $10 to this label. Once we’ve made such an assignment, we can refer¬ 
ence this label in the body of the program. When the assembler is assem¬ 
bling the program, it will automatically substitute any constant labels it 
finds in the body of the program with their numerical equivalents. For 
example, the assembler will automatically substitute the clrcode label 
associated with the lda instruction with the data value $10. 

In the same way that we can use constant labels to represent data 
values, we can also use them to depict addresses. Consider two further 
modifications to our program: 


CLRCODE: 

.EQU 

$10 

# 

Special code to clear the main display 

MAINDISP: 

.EQU 

$F031 

# 

Address of output port for main display 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Store accumulator to main display 


JMP 

[$0000] 

# 

Jump to address $0000 


.END # This is the end of the program 

Here we see a second constant label called maindisp, which is assigned 
a value of $F031 (the address of the output port driving the calculator’s 
main display). This label is subsequently used with the STA instruction in 
the body of the program. 

Note that although the program’s source code has been modified, 
the resulting machine code will be identical to our original program be¬ 
cause all the assembler is doing is substituting these labels for their nu¬ 
merical equivalents. 

Even though each of these labels is used only a single time in this ex¬ 
ample, their presence makes the program significantly easier to read and 
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understand, which will become increasingly important as our programs 
grow in complexity. Using labels also facilitates modifying programs. For 
example, if we were to use the clrcode label multiple times in the body of 
the program, then we would only have to change the original assignment 
in the . EQU statement to affect every instance throughout the program. 

Testing the New Program 

Enter the above changes into the lab2b.asm assembly source file, and then 
assemble the program to generate the corresponding lab2b.ram file by se¬ 
lecting the File > Assemble pull-down menu in the assembler’s menu bar 
(or by clicking the appropriate icon on the assembler’s tool bar). 
Assuming you don’t have any errors and your program assembles suc¬ 
cessfully, you can now exit the assembler to make room on your screen. 

Click the On/Off button to power-up the calculator. (If you didn’t 
power the calculator down after the previous lab, click the On/Off but¬ 
ton two times; the first time to power it down and “scramble” its memo¬ 
ry and the second time to power it up again.) 

Now use the main window’s Memory > Load RAM pull-down 
menu to locate the lab2b.ram file you just created and load its contents 
into the calculator’s memory. Next, click the calculator’s Run button to 
execute this new version of the program and note that it behaves exactly 
the same as it did before, which is to load the accumulator with the $10 
clear code, write this code to the output port driving the calculator’s 
main display, and then jump to address $0000. 

A Few Simple Rules 

During future labs you’ll come to see that constant labels, along with 
their address-label cousins, which are introduced in Lab 2c, are excep¬ 
tionally useful. There are just a few simple rules you should attempt to 
memorize before proceeding to the next lab: 

• Constant labels are declared using . EQU directives, and all such 
statements must occur before the program’s . ORG directive. 

• Each constant label may be declared only a single time, but they 
can subsequently be used multiple times within the body of the 
program. 
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• Labels can consist of a mixture of alphabetic, numeric, and un¬ 
derscore characters (no spaces or other special characters are 
allowed), but the first character must be either an alpha or an un¬ 
derscore (not a numeric). 

• When a label is declared it is terminated with a colon charac¬ 
ter, but this character does not form part of the label’s name and 
is not used thereafter. 

• The maximum length of a label is eight characters. This includes 
any underscores, but excludes the colon character used to termi¬ 
nate the label’s declaration. 

• Labels can include both uppercase and lowercase characters, but 
the assembler internally converts everything to uppercase, so it 
will consider labels such as f red, Fred, FrEd, and FRED to be 
identical. 

• Last but not least, assignments to constant labels may employ 
simple equations and may reference other constant labels. How¬ 
ever, if these equations do reference other constant labels, then 
those labels must be defined before they are used.^ For example: 


Valid 



Not Valid 


FRED: 

.EQU 

$10 

BERT: 

.EQU 

(ERED + 2 

BERT: 

.EQU 

(ERED + 2) 

ERED: 

.EQU 

$10 

etc. 



etc. 




The assignment to BERT can The assignment to BERT cannot 

reference FRED, because ERED reference ERED, because ERED 

has already been declared. has not yet been declared. 

Note that, unlike the constant labels shown here, their address la¬ 
bel cousins (as introduced in Lab 2c) can be referenced both be¬ 
fore and after they are used. 


Hhis is just the way in which our assembler happens to work because it’s a simple way of 
doing things. It would certainly be possible to create an assembler that did support/or- 
ward referencing for constant labels (where “forward referencing” means referencing 
something that has not yet been declared). 
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Driving the Calculator's 
Main Display 


Objective: To learn how to output data to the calculator’s main 

display. 

Duration: Approximately 25 minutes. 

Viewing the Interface as 
Discrete Chunks 

Conceptually, the calculator’s front panel consists of four discrete 
“chunks” (Figure L2-8). At the bottom-left of the panel are four special 
buttons that are used to control the virtual computer that we can visual¬ 
ize as lurking “behind” the front panel. The On/Off and Reset buttons 
are connected directly to the computer’s power supply and reset input, 
respectively (the Step and Run buttons will be discussed in more detail 
later). 

The middle of the panel is dominated by the keypad area, whose 
function and operation are discussed in Lab 2d. Above the keypad is a 
bank of six light-emitting diodes (LEDs), whose workings are introduced 
in Lab 2e, whereas the top of the panel is commanded by the calculator’s 
main display (Figure L2-9). 

The Main Display’s Character Codes 

The calculator’s main display is driven by the output port at address 
$F031 (all of the input and output ports are 8 bits wide to match the 
system’s 8-bit data bus.) 

We may consider this display as containing a small amount of in¬ 
ternal logic that functions autonomously from the main (virtual) com- 
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Figure L2-8. The calculator front panel consists of four “chunks.” 


puter. For example, when the CPU writes an 8-bit value to the port dri¬ 
ving the display, any characters that are currently being displayed will be 
automatically shifted one place to the left and the new character (corre¬ 
sponding to the value written to the port) will appear at the right-hand 
side of the display. All of this character movement and organization is 
performed by the display itself, independent of the virtual computer. 


From the 
CPU 


Output port at 
address $F031 



Figure L2-9. The calculator’s main display. 
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(a) 


(b) 


72 




$07 from 
the CPU 

$02 from 
the CPU 



As a simple example (assuming the display to be initially cleared), 
writing a series of codes such as $07, $02, $05, and $09 to this port will 
cause the display to show 7, 72, 725, and 7259, respectively (Figure L2-10). 

To further increase our programming pleasure, the calculator’s 
main display supports a relatively rich set of alphanumeric, punctuation, 
and special characters (Figure L2-11). 

This character set is very similar to the American Standard Code for 
Information Interchange (ASCII), which was introduced in 1963 to facili¬ 
tate disparate computers “talking” to each other. (Note that ASCII code 
$20 (“SP”) will display a space “ ” character.) Among other things, sup¬ 
porting this character set means that we can actually present messages 
like “Hello World” on the display if we so desire (in fact we’ll be doing 
this in Lab 2f). 

However, our character set also boasts some variations from stan¬ 
dard ASCII, including the fact that we’re using codes $00 through $09 


LQ^I ASCII, pronounced started life as a 7-bit code. Thus, the most significant bit in an 8-bit 

byte was either set to 0 (as in our implementation) or was used to implement a simple form of error 
checking known as parity checking. 

Error checking is of use when information is being passed from one system (or subsystem) to another. For 
example, consider the letter “S” for which the 7-bit ASCII code is $53 (or 1010011 in binary). In the case of 
even parity, the most significant bit would be set or cleared so as to maintain an even number of “ 1 ”s in an 
8-bit byte. Thus the even parity version of the code for the letter “S” would be 01010011. By comparison, 
11010011 would be the value used in an odd parity scheme. 

The idea is that the transmitting system calculates the parity bit and sends it as part of that byte. For each 
byte, the receiving system recalculates the parity bit from the first seven bits it sees, and it then compares 
this bit to the parity bit from the transmitter. Any discrepancy between the two parity bits indicates that 
some form of corruption occurred during the transmission. 
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Not Standard ASCII Standard ASCII 
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Figure L2-11. Character codes supported by the main display. 


and $0A through $0F to represent the numeric characters “0” through 
“9” and the hexadecimal characters “A” through “F,” respectively. Also, 
we’re using code $10 (“Clr”) as a special instruction that will clear the 
display, code $11 (“Bell”) to cause the interface to “beep” in an annoying 
fashion, and code $12 (“Back”) to cause the display to clear the last 
(right-most) character and shift any remaining characters one place to 
the right. ^ 

Last, but not least, codes $13 through $1F (along with code $7F) 
have been left undefined, which means you use them at your peril. 

hn the case of standard ASCII, codes $00 through $IF were used to represent special con¬ 
trol and formatting characters, such as STX (“start of text”), CR (“carriage return”), LF 
(“line feed”), ACK (“acknowledge”), and EOT (“end of transmission”). As some of these 
appellations suggest, these characters could be used to control things like printers and 
old-fashioned Teletype terminals. 
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The Status Register (SR) 

In this lab we’re going to create a program that writes to the calculator’s 
main display, but before we proceed there’s another register in the CPU 
that deserves mention: the status register (SR) (Figure L2-12). 

Each bit in the status register is called a status bit, but they are also 
commonly referred to as status flags or condition codes, because they serve 
to signal (flag) that certain conditions have occurred. We shall introduce 
each of these bits and describe how they work as we progress through 
these labs. 

Since we may sometimes wish to load the status register from (or 
store it to) the memory, it is usual to regard this register as being the 
same width as the data bus (8 bits in the case of our system). However, 
our CPU employs only five status flags, which occupy the five least-sig¬ 
nificant bits of the status register. This means that the three most-signifi¬ 
cant bits of the register exist only in our imaginations, so their nonexis¬ 
tent contents are, by definition, undefined. Finally, you need to be aware 
of one more convention as follows: 

• A status flag is said to be “set” if it contains a 1, which is used to 
indicate a “true” condition. For example, if the zero flag is set 
(contains a 1), this indicates that: “It’s TRUE to say that the cur¬ 
rent value stored in the accumulator (ACC) is zero” (that is, all 
of the bits in the accumulator contain Os). 



Figure L2-12. The status register (SR). 
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• A status flag is said to be “cleared” if it contains a 0, which is used 
to indicate a “false” condition. For example, if the zero flag is 
cleared (contains a 0), this indicates that: “It’s FALSE to say that 
the current value stored in the accumulator is zero” (that is, one 
or more of the bits in the accumulator contain Is). 

Unfortunately, this can appear somewhat counterintuitive; espe¬ 
cially in the case of the zero flag, where a 1 in the flag indicates that the 
accumulator contains all Os and a 0 in the flag means that some of the 
bits in the accumulator are 1. It does take a little effort to wrap your 
brain around this convention the first time you see it, but you’ll find that 
it really does make sense once you get into the swing of things (especially 
when we come to consider the other status flags). 

We should also note that, although the zero flag is predominantly 
used to indicate whether or not the accumulator currently contains a 
zero value as was just discussed, this flag is multifaceted and can be used 
to indicate other conditions depending on the actual operation being 
performed. As one example, see the discussions on the cmpa instruction 
in Lab 2d (and also peruse the Just When You Started to Feel Happy sec¬ 
tion at the end of this lab). 


Writing to the Main Display 

If you haven’t already done so, launch the main DIY Calculator and then 
invoke the assembler. Now use the assembler’s File > Open command to 
access the lab2b.asm file you created in the previous lab, and then use the 
File > Save As command to rename and save this file as lab2c.asm, which 
should appear as follows: 


CLRCODE: 

.EQU 

$10 

# 

Special code to clear the main display 

MAINDISP: 

.EQU 

$F031 

# 

Address of output port for main display 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Store accumulator to main display 


JMP 

[$0000] 

# 

Jump to address $0000 


.END 


# 

This is the end of the program 


As you will recall, this program loads the accumulator with a value of 
$10, stores this value to the output port driving the main display (there¬ 
by clearing the display), and jumps to address $0000, which terminates 
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the program. But this time our program is going to do something differ¬ 
ent, because we’re going to augment it so as to write some numbers to 
the display (Figure L2-13). 

The flowchart blocks representing our original program are shown 
in white, while any new extensions are shaded gray. Once this new ver¬ 
sion of the program has cleared the screen, it’s going to load the accumu¬ 
lator with a value of $09 (or 9 in decimal). The program now enters a 
loop, which consists of copying (storing) the value in the accumulator to 
the display, decrementing (subtracting 1 from) the accumulator, and 
then testing to see whether to display the accumulator’s new contents (if 
they’re nonzero) or terminate (if they’re zero). Note that this test is rep¬ 
resented as a diamond shape in the flowchart in order to differentiate it 
from the actions, which are shown as rectangles. As we shall see, this will 
result in the characters “987654321” appearing on the display. 


Modifying the Program 

Without any further dilly-dallying or shilly-shallying, modify your pro¬ 
gram as shown below (the changes are highlighted in gray): 


CLRCODE: 

• EQU 

$10 

# 

Special code to clear the main display 

MAINDISP: 

• EQU 

$F031 

# 

Address of output port for main display 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Store accumulator to main display 


LDA 

$09 

# 

Load the accumulator with $09 

LOOP: 

STA 

[MAINDISP] 

# 

Store accumulator to the main display 


DECA 


# 

Decrement the accumulator 


JNZ 

[LOOP] 

# 

Jump to LOOP if ACC isn't zero 


JMP 

[$0000] 

# 

Jump to address $0000 


.END 


# 

This is the end of the program 


These modifications include two new instructions. The first is DECA 
(“decrement accumulator”), which subtracts 1 from the existing contents 
of the accumulator. This instruction is said to use the implied addressing 
mode because it comprises only an opcode without an operand. In this 
case, any data required by the instruction, and the destination of any re¬ 
sult from the instruction, are implied by the instruction itself. (There is 
also a corresponding INCA {“increment accumulator”) instruction that 
we can use to add 1 to the existing contents of the accumulator.) 
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Figure L2-13. Flowchart for a program that writes numbers to the main display. 


The second new instruction is JNZ (“jump if not zero”), which is a 
special form of jump with a condition attached to it. In fact, this is one of 
a pair of instructions that decide whether or not to jump based on the 
contents of the Z (zero) status flag. Just for the moment, however, let’s 
forget about the Z flag per se, and instead simply say that: 

• The JZ (“jump if zero”) instruction will only jump to a specified 
address if the current value stored in the accumulator (ACC) is 
zero (that is, all of the bits in the accumulator contain Os); other¬ 
wise the test will fail and the program will simply continue to the 
next instruction. 

• By comparison, the JNZ (“jump if not zero”) will only jump to a 
specified address if the ACC contains a nonzero value (that is, 
one or more of the bits in the accumulator contain Is); otherwise 
the test will fail and, once again, the program will simply contin¬ 
ue to the next instruction. 

Our modifications also include a label called LOOP. This is a new type of 
label known as an address label, whose value (as “seen” by the assembler) 
is the memory location of the instruction with which it’s associated (the 
program’s second STA instruction in this case). This means that whenev¬ 
er the LOOP label is referenced elsewhere in the program (such as by the 
JNZ instruction in the above example), the assembler will automatically 
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substitute the address of the memory location containing the STA op¬ 
code. (Note that, unlike the constant labels introduced in Lab 2b, address 
labels can be referenced before they have been declared. This isn’t the case 
in this particular program, but we’ll see lots of examples of this type of 
forward referencing in the not-so-distant future.) 

In order to see how the address label actually works, let’s consider 
the actions performed by our new statements. After clearing the main 
display, the lda $ 0 9 instruction is used to load the accumulator with 
$09, which is going to provide the loop with an initial value. The subse¬ 
quent STA [MAINDISP] instruction now stores the current value in the 
accumulator to the output port driving the main display, thereby causing 
the character “9” to appear at the right of the display area. 

Next, the deca instruction subtracts 1 from the value in the accu¬ 
mulator, which leaves the accumulator containing $08. As this value is 
nonzero, this means that the JNZ (“jump if not zero”) instruction will 
cause the program to jump back to the label loop, at which point the STA 
[MAINDISP] will once again store the current value in the accumulator 
to the output port driving the main display. This will cause the “9” that’s 
already on the display to be shifted one place to the left and an “8” to ap¬ 
pear next to it, thereby resulting in a value of “98” on the display. 

And so it goes. The program will keep on racing around the loop 
until the display contains “987654321,” at which point executing the 
DECA instruction will result in the accumulator containing zero. This 
means that the JNZ instruction will fail and the program will drop 
through to our original JMP $ 0 0 0 0 instruction, which, when executed, 
will cause the program to terminate. 


Testing the Program 

To see all of this happen on the real display, first assemble your program 
to generate the corresponding lab2c.ram file. Assuming you don’t have 
any errors and your program assembles successfully, you may now exit 
the assembler. 

Click the On/Off button to power-up the calculator. (If you didn’t 
power the calculator down after the previous lab, click the On/Off but¬ 
ton two times; the first time to power it down and “scramble” its memo¬ 
ry, and the second time to power it up again.). Now use the main DIY 
Calculator window’s Memory > Load RAM pull-down menu to locate 
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the lab2c.ram file you just created and load its contents into the calcula¬ 
tor’s memory. Next, click the calculator’s Run button to execute this new 
version of our program and observe the characters “987654321” appear 
on the display. 


Just When You Started to Feel Happy 

We’d just like to say in advance that we’re sorry about what we’re poised 
to do to you, which is to (metaphorically) squeeze your brain until your 
eyes water. 

Earlier in this lab, we stated: “Just for the moment, let’s forget 
about the Z flag per se, and instead simply say that. . . .” And then we 
presented you with the following definitions: 

• The JZ (“jump if zero”) instruction will only jump to a specified 
address if the current value stored in the accumulator (ACC) is 
zero; otherwise the test will fail and the program will simply con¬ 
tinue to the next instruction. 

• By comparison, the JNZ (“jump if not zero”) will only jump to a 
specified address if the ACC contains a nonzero value; otherwise 
the test will fail and, once again, the program will simply contin¬ 
ue to the next instruction. 

Sad to relate, this was a case of “the quickness of the hand deceives 
the eye.” These definitions are certainly true for the program in this lab, 
but life is a tad more complicated than we’ve lead you to believe. The 
problem is that we typically think of the JZ and JNZ instructions in the 
context of the accumulator. In reality, however, the Z flag can be used to 
indicate other conditions; for example, consider the cmpa (“compare ac¬ 
cumulator”) instruction, which is used to compare two numbers (this 
instruction is introduced in Lab 2d). In this case, the Z flag is set to 1 if 
the two numbers are equal; otherwise it is cleared to 0. 

Thus, more precise definitions of the operation of the JZ and JNZ 
instructions are as follows: 

• The JZ (“jump if zero”) instruction will only jump to a specified 
address if the Z flag contains a 1 (a “true” condition); otherwise 
the test will fail and the program will simply continue to the next 
instruction. 
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• By comparison, the JNZ (“jump if not zero”) will only jump to a 
specified address if the Z flag contains a 0 (a “false” condition); 
otherwise the test will fail and the program will simply continue 
to the next instruction. 


You might be forgiven for thinking we’re wandering off into the weeds here, reminiscent of the 
now famous statement by U.S. State Department Spokesman Robert McCloskey: 


“I know you believe that you understood what you think I said, but I am not sure you realize that 
what you heard is not what I meant.” 


So what does all of this really mean? Well, the decision symbol (the 
diamond) in the flowchart in Figure L2-13 is based on the contents of 
the accumulator. Another way to think about this would be to base this 
symbol on the contents of the Z flag (Figure L2-14). 

Observe that the “yes” and “no” annotations associated with the 
decision symbols are swapped between the two figures. This is because a 
0 in the Z flag indicates a nonzero value in the accumulator, whereas a 1 
in the Z flag indicates a zero value in the accumulator. 

Note that the “!” character (sometimes referred to as a “bang” or a 
“shriek”) is often used to indicate an inversion or a negative (“not”) 
state, so the string “ACC != 0” in Figure L2-14 indicates “ACC is not 
equal to zero.” By comparison, a pair of equals signs “==” is used to in¬ 
dicate a logical equivalence (as opposed to an assignment implied by a 
single equal sign “=”), so the string “ACC == 0” in Figure L2-14 is used 
to indicate that “ACC is logically equal to zero.” 

Don’t panic if all of this seems overly confusing; everyone feels that 
way when they first grapple with this topic.^ In fact, the only reason 


Jump to 
new address 


From last 
instruction 


Continue to 
next instruction 




Z (zero) flag 

The CPU "looks" at the Z flag to 
see If It contains a 0 (ACC != 0) 
ora 1 (ACC == 0) 


Figure L2-14. The JNZ causes a jump if the Z flag is zero. 
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we’ve labored this point into the ground is that the Z flag can be used to 
indicate a variety of conditions depending on the actual operation being 
performed. For the moment, however, we can forget all about the inner 
machinations of the Z flag, and need only remember that, in the case of 
this program, the JNZ instruction means “Jump to the specifled address 
if the accumulator contains anything other than $00.”) 

In the section of this lab entitled The Main Display’s Char¬ 
acter Codes, why do you think we decided to make the main display ac¬ 
cept codes $00 through $09 as representing the numeric characters “0” 
through “9” when these characters are already provided by the standard 
ASCII codes $30 through $39. Similarly, why did we make the main dis¬ 
play accept codes $0A through $0F as representing the hexadecimal char¬ 
acters “A” through “F” when ASCII codes $41 through $46 already pro¬ 
vide these characters? 


■SUOTSJ3AUOD L]3ns Am miojrad 

01 SuiAoij inoijjpw dB|dsTp aiji oj dpoarip san^BA asaqj indino oi sn SMopo 
ijSnoriji «6„ itSnorqi srapBiopo aqj Supuasajdar so qo$ qSnorq; 

00$ sapoa idaoDo o; dBydsip roiB{napa rno SupuauiSny -STuapAmba IDSV 
jpqi ojui uiaqj iraAuoa oj luaqi oj (V0$ - It'S) PP^ ot s^oq isiq ppoAv aw 
‘(«d„ qSnojqi ^q^ip pmpapBxaq aqi Supuasardar) n 110000% qSnorqi 
01010000% aSuBJ aqi m sanpAindjno o; japio ui ‘Xpoquiig -sjuaiBAmba 
IIDSV rpqi oiui maqi jraAuoa o; uiaqj o; 0€$ PP^ o; aArq isnj pinoAv aw ‘(„6„ 
qSnojqi ^^o„ sqSip puipaprxaq pur puipap aqi Supuasardar) 10010000% 
qSnojqj 00000000% sSubj aqi ui sanpA jndjno o; paqsiAv aw jaAauaqw 
uaqi ‘sapoa iDgv pJBpuBjs diuo pajdaaar Xoidsip roiBinapa aqi ji j3msu\/ h 


^Alternatively, if you’re feeling frisky and saying to yourself: “WeU, that was pretty sim¬ 
ple. I really don’t know what they were making all the fuss about,” then put away these 
notes, grab a friend, and try articulating the way in which we can view the JN and JNZ 
instructions working in the context of (a) the ACC and (b) the Z flag. 
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Reading from the 
Calculator's Keypad 


Objective: To learn how to read data from the calculator’s keypad. 

Duration: Approximately 25 minutes. 

Keypad Buttons and Codes 

In the previous lab, we discovered how to drive the calculator’s main dis¬ 
play. The next thing we need is some data to display, and one source of 
data is the calculator’s keypad (Figure L2-15). 

Each of the calculator’s buttons has a code associated with it, where 
these codes are shown as hexadecimal values in parenthesis. For example, 
$16 and $1A are the codes associated with the “-I-” and “=” buttons, re¬ 
spectively. 

The calculator interface contains an 8-bit latch whose outputs drive 
our virtual computer’s input port at address $F011. (For our purposes 
here, a latch may be considered to be another name for a register; that is, 
a group of memory elements, each of which can store a single bit.) When 
the calculator is first powered-up using the front panel’s On/Off button 
(not shown in Figure L2-15), this latch is automatically loaded with a de¬ 
fault value of $FF. This default value remains in the latch until we click 
one of the calculator’s buttons, at which point the code associated with 
that button is loaded into the latch. Once a button code has been loaded 
into the latch, it remains there until one of two things occur: 

a) We click another button, which causes its code to be loaded into 
the latch. 

b) The CPU (directed by one of our programs) reads data from the input 
port at address $F011. In addition to copying the current value stored 
in the latch into the accumulator, a special (virtual) electronic circuit 
automatically causes the latch to be reloaded with its default $FF value. 
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rvi 
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Bin 

u 

Dec ‘ 


Hex 

($45) 


($44) 


($43) 


($42) 


($41) 


($40) 


($26) 

($2B) 

($30) 

($35) 

Sin 

($3A) 

x'V 

($3F) 

($25) 

($2A) 

($2F) 

($34) 

Cos 

($39) 

($3E) 

($24) 

($29) 

($2E) 

($33) 

Tan 

($38) 

x^2 

($3D) 

($23) 

($28) 

($2D) 

($32) 

Log 

($37) 

Rx 

($3C) 

($22) 

($27) 

($2C) 

($31) 

n! 

($36) 

1/x 

($3B) 


7 

($07) 

8 

($08) 

9 

($09) 

($19) 

Mod 

($1D) 

Exp 

($21) 

4 

($04) 

5 

($05) 

6 

($06) 

($18) 

Pi 

($1C) 

F-S 

($20) 

1 

($01) 

2 

($02) 

3 

($03) 

($17) 

( 

($1B) 

) 

($1F) 

0 

($00) 

+/- 

($14) 

($15) 

+ 

($16) 

($1A) 

($1E) 

A 

($0A) 

B 

($0B) 

c 

($0C) 

D 

($0D) 

E 

($0E) 

F 

($0F) 




Clear 

CE 

Back 

Enter 

($10) 

($11) 

($12) 

($13) 






To the 
CPU 


t 

8-bit 

Latch 


Input port at 
address $F011 


Figure L2-15. The calculator’s keypad and associated codes. 


The fact that reading from the port causes the latch to be reloaded with 
$FF is important, because, as we shall see, it provides a way for our pro¬ 
grams to detect whether or not a key has been pressed. Also, you will ob¬ 
serve that although many of the keys have annotations, some remain 
blank. The annotated keys are those for which we have already decided 
the function they are to perform (we’U tell you how to modify these ex¬ 
isting annotations or add new ones to the blank keys later). In addition 
to the buttons marked “0” through “9” and “A” through “F” (which can 
be used to represent decimal and hexadecimal digits), we have made the 
following assignments: 


Code 

Annotation 

Intended Function 

$10 

Clear 

Clear the current calculation and the main display 

$11 

CE 

Clear the current value on the main display 

$12 

Back 

Clear the last displayed character 

$13 

Enter 

Indicates the end of a numerical value^ 

$14 

+1- 

Change the sign of a value from + to - or vice versa^ 


^This is used in the case of the reverse Polish notation {RPN) scheme introduced in 
Chapter 5. 

^The actions of the +/- button will eventually be context sensitive in the case of floating 
point values; that is, we may wish to change the sign of the mantissa and/or the exponent 
in scientific-notation numbers (this is covered in more detail on the DIY Calculator’s 
website). 
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$15 


Decimal point 

$16 

+ 

Add 

$17 

- 

Subtract 

$18 

* 

Multiply 

$19 

1 

Divide 

$1A 

= 

Equals 

$1B 

( 

Left parenthesis 

$1F 

) 

Right parenthesis 

$1C 

Pi 

The constant tt 

$1D 

Mod 

Displays the modulus (remainder) of a division 

$20 

F-S 

Toggle between scientific notation being on/off 

$21 

Exp 

Used to enter an exponent in scientific notation 

$36 

n! 

Calculate the factorial of the value on display 

$37 

Log 

Calculate the logarithm of the value on display 

$38 

Tan 

Calculate the tangent of the value on display 

$39 

Cos 

Calculate the cosine of the value on display 

$3A 

Sin 

Calculate the sine of the value on display 

$3B 

1/x 

Calculate the reciprocal of the value on display 

$3C 

Rx 

Calculate the square root of the value on display 

$3D 

xA2 

Calculate the square of the value on display 

$3E 

xA3 

Calculate the cube of the value on display 

$3F 

xAy 

Calculate x raised to the yth power 

$40 

Ffex 

Enter and display values in hexadecimal 

$41 

Dec 

Enter and display values in decimal (the default) 

$42 

Bin 

Enter and display values in binary 


Although the above list sounds rather grand, especially if you read it 
quickly and aloud, it’s worth remembering that none of these buttons ac¬ 
tually do anything yet! At the moment, the only action that occurs when 
you click a button is for the code associated with that button to be loaded 
into the calculator’s 8-bit latch. The purpose of this book is to teach you 
how to create the programs that will cause at least some of these buttons 
to actually do something useful. 
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With regard to the unassigned buttons with codes $1E, $22 through 
$35, and $43 through $45, these buttons have been left free for you to use 
as you wish. You can reconfigure the front panel to modify the legends 
on the buttons, change the colors of the legends, and so forth. These 
aspects of the front panel are introduced in more detail in Chapter 6. 


Reading Codes from the Keypad 

You should know the drill by now. If you haven’t already done so, 
launch the main DIY Calculator and then invoke the assembler. Now use 
the assembler’s File > Open command to access the lab2h.asm file you 
created in an earlier lab, then use the File > Save As command to rename 
and save this file as lab2d.asm, which should appear as follows: 


CLRCODE: 

.EQU 

$10 

# 

Special code to clear the main display 

MAINDISP: 

.EQU 

$F031 

# 

Address of output port for main display 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Store accumulator to main display 


JMP 

[$0000] 

# 

Jump to address $0000 


.END 


# 

This is the end of the program 


You should be able to write this particular program in your sleep by this 
time! All it does is to load the clear code $10 into the accumulator, write 
this code to the port driving the main display, and then terminate the 
program by jumping to address $0000. But, as usual, this is just a starting 
point, because we are going to modify the program such that it waits for 
a button to be pressed and, if that button corresponds to “0” through “9” 
(that is, one of the buttons carrying the “0” through “9” annotations), 
writes this value to the main display (Figure F2-16). 

As usual, the flowchart for our original program is shown in white, 
whereas any extensions are shown in gray. Note that we’re going to lose 
the JMP [$0000] instruction from the end of the original program, be¬ 
cause our new program never actually ends. Once the clear code has been 
written to the main display, the program enters a series of nested loops, 
which means that we have an inner loop “nested” inside one or more 
higher-level loops. 

First, the program loops around, reading values from the input 
port at address $F011 (the port connected to the calculator’s latch) and 
loading them into the accumulator. The program keeps on doing this 
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Figure L2-16. Flowchart for a program to read from the keypad and write to the 
display. 


until it detects a value other than $FF, at which point it knows that a but¬ 
ton has been pressed. (Remember that the act of reading from this port 
automatically causes the latch to be reloaded with its original $FF value.) 

Next, the program tests to see if the code for this button is greater 
than $09, in which case it won’t perform any actions, but will simply re¬ 
turn to wait for another button to be pressed. Only if the code is between 
$00 through $09, inclusive (corresponding to the ‘0’ through ‘9’ but¬ 
tons), will the program write this value to the calculator’s main display 
and then return to wait for the next button to be pressed. So now is the 
time to modify our program as shown below (the changes are highlight¬ 
ed in gray): 


CLRCODE: 

-EQU 

$10 

# 

Special code to clear the main display 

MAINDISP: 

• EQU 

$F031 

# 

Address of output port for main display 

KEYPAD: 

.EQU 

$F011 

# 

Address of input port for keypad 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Store accumulator to main display 

LOOP: 

LDA 

[KEYPAD] 

# 

Load the accumulator from the keypad 


JN 

[LOOP] 

# 

Jump to LOOP if N flag is set 


CMPA 

$09 

# 

Compare accumulator to code $09 


JC 

[LOOP] 

# 

Jump to LOOP if C flag is set 


STA 

[MAINDISP] 

# 

... else store accumulator to display 


JMP [LOOP] # Jump to LOOP 

JMP - [$0000] - ft Jump to addrooa $0000 


# This is the end of the program 


The first change is to introduce a new constant label called keypad, 
and to assign it the address of the input port driven by the latch connect- 
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ed to the calculator’s keypad. After clearing the main display, the lda 
[KEYPAD] instruction loads the accumulator from the latch. A new fla¬ 
vor of instruction —JN (“jump if negative”)—is now used to jump back 
to the LOOP label if the N (negative) flag in the status register contains a 
1 (Figure L2-17). [Note that there is also a corresponding JNN (“jump if 
not negative”), which will jump if the N flag contains a 0.] 

To be honest this is a bit unfair, because there are a couple of things 
we haven’t told you yet. (Actually, there’s a whole lot we haven’t told 
you, but we will—oh yes, we will. Be afraid. Be very afraid.) First of all, 
it’s up to us to decide what the contents of the accumulator represent at 
any particular point in time. For example, at some stage during our pro¬ 
gram we might consider the accumulator to contain only positive values, 
but a little later we could do a complete about-face and decide that it can 
contain both positive and negative values (aU of this is explained in 
excruciating detail in Chapter 4). 

If we assume that the accumulator can contain both positive and 
negative values, then we can use its most-significant bit (MSB) to differ¬ 
entiate between them (a 0 or 1 in the MSB indicates a positive or nega¬ 
tive value, respectively). The trick here is that the N (negative) status flag 
typically contains a copy of whatever is in the most-significant bit of the 
accumulator. As the calculator’s default $FF code (which equates to 
%11111111 in binary) is the only code the front panel’s latch will ever 
contain that has a 1 in its most-significant bit, the JN instruction will 
only jump back to the loop label if no key has been pressed. 

If a key has been pressed, the JN instruction fails and the program 
continues to the CMPA (“compare accumulator”) instruction, which 
compares the contents of the accumulator to the value $09. This opera¬ 
tion assumes that both of the values being compared are positive values 


Jump to 
new address 




From last 
instruction 




N (negative) flag 


next instruction ^ 


Continue to 


The CPU "looks" at the N flag to 
see if it contains a 1 (ACC < 0) 
or a 0 (ACC >= 0). 


Figure L2-17. The IN causes a jump if the ACC contains a negative value. 
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(remember that it’s up to us to decide what we want the contents of the 
accumulator to represent at any particular time). The ways in which the 
CMPA instruction presents the results of its comparison are as follows: 

• The C (carry) status flag will be loaded with a 1 if the value in 
the accumulator is larger than the value it’s being compared to; 
otherwise the C flag will be cleared to 0.^ 

• The Z (zero) status flag will be loaded with a 1 if the value in the 
accumulator is equal to the value with which it’s being compared; 
otherwise it will be cleared to 0. 

In the case of this particular program, the only keys of interest are 
those with codes of $00 through $09. If the value in the accumulator is 
greater than $09, the CMPA instruction will cause the C (carry) flag to be 
set to a 1. In turn, this will cause the JC (“jump if carry”) instruction to 
jump back to LOOP (Figure L2-18). (As usual, there is a corresponding 
JNC (“jump if not carry”) instruction, which will jump if the C flag con¬ 
tains a 0.) 

If the JC instruction fails, this means that the value in the ac¬ 
cumulator is in the range $00 through $09, in which case the STA 
[MAINDISP] instruction is used to store this value to the output port 
driving the calculator’s main display. Finally, the JMP (“jump uncondi¬ 
tionally”) instruction returns the program to LOOP to wait for the next 
button to be pressed. 

Testing the Program 

In order to see this work with the real display, first click the assemble 
icon on the assembler’s tool bar to generate the corresponding lab2d.ram 
file and then either minimize or exit the assembler. 

Click the On/Offbutton to power-up the calculator. (If the calcula¬ 
tor is already powered-up, use the Memory > Purge RAM command to 
“scramble” its memory). Now use the Memory > Load RAM command to 
locate the lab2d.ram file you just created and load its contents into the cal¬ 
culator’s memory. Next, click the calculator’s Rim button to execute this 
new version of our program. Observe that, as soon as the display is cleared, 
the program starts to loop around waiting for you to click a button. 

^The C (carry) flag is perhaps the most multifarious of all the status flags, in that it is used 
for a multitude of different purposes, as we shall come to discover in future labs. 
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Jump to 
new address 



From last 
instruction 



C (carry) flag 


Continue to 
next instruction 


The CPU "looks" at the C flag to see if it 
contains a 1 orO (the meaning of which 
depends on the previous instruction). 


Figure L2-18. The JC causes a jump if the C (carry) status flag contains a 1. 

Experiment by clicking the buttons “0” through “9” and note the 
effect. Also note that even when the display is full, clicking further but¬ 
tons simply causes the new digits to appear at the right-hand side of the 
display, whereas the most-significant digits “fall off’ the left-hand side of 
the display. Now click any of the other buttons on the keypad {excluding 
the On/Off, Reset, Step, and Run control buttons) and observe that 
nothing happens. This is because our new program is written in such a 
way that it ignores them. 

Once you are sated with your newfound power, click the On/Off but¬ 
ton to power-down the calculator, and then consider the question below. 

IJMiliUI We didn’t actually need to use the JN [loop] instruction 
in our program. Why not? 


•uouriU3ui3{duiT roiUDurod siqj ui snonpradns si np aqt jrqj suoaui 
qDiqM ‘cIOOT: oj qaoq dum( oj uopomism of sqj asnuD ppoM roiopui 
-UDDo aqr ui ;jq$ JO an^BA b ‘pauiuio araw uopanrisui np aqt j; uaAa ‘snqj^ -goS 
JO an^BA B UBqi ra8jB| aq oi qjg jo an^BA b lapisuoa qiM ji os ‘sraSarui aAijisod aro 
SuuBduioa spi san^BA aqi samnssB uoipurism vdWD aqi trqi si ruiod aqj[ 

"dOOT oj qoBq dumt oj uoipnrisui 
or aqi asnBD qiM qaiqM ‘j b qiiM papBOj si Sb^ Anno aqi ‘jaSiB^ aqi oin 
sruaiuoa spoppumaDB aqj jj '60$ aufBA aqj oj jojB{nmnaaB aqj jo sjuaiuoa aqi 
ajBduioa oj pasn si uoipuusui vdwo aqj ‘sjibj np aqj jj 'dOOT oj qouq sdumf 
uiBiSord aqi asBO qaiqAv ui ‘(passard uaaq aABq suounq ou pqj SuiuBaui) apoa 
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Writing to 

Calculator's Six LEDs 


Objective: To learn how to control the six LEDs on the calculator. 

Duration: Approximately 30 minutes. 

The Calculator’s Six LEDs 

As you will recall, there are six buttons on the front panel appearing just 
below the main display and just above the main keypad area. Three of 
these buttons have annotations (Bin, Dec, and Hex), whereas the others 
are as yet undefined. To the left of each of these buttons is a simple 
light-emitting diode (LED), which we can turn on or off as we choose 
(Figure L2-19). 

It’s important to note that there is no intrinsic relationship between 
the Bin, Dec, Hex, and similar buttons and these LEDs apart from their 
being physically close together on the calculator’s front panel. The LEDs 
are driven by an output port at address $F032, and any values written to 
this output port are totally under the control of our programs. This 
means that the only relationships between the LEDs and any of the key¬ 
pad’s buttons are those we decide to implement. 

Writing to the Six LEDs 

You’ll be pleased to hear that this program is going to be short, sharp, 
and sweet. All we’re going to do is to create a loop that flashes the LEDs 
in sequence (Figure L2-20). 

As you will observe, this flowchart assumes we are keeping the two 
instructions from our earlier programs that are used to clear the main 
display. In fact there’s no particular reason to clear the main display here. 
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Output port at 
address $F031 



From the 
CPU 


From the 
CPU 

Output port at 
address $F032 


Figure L2-19. The calculator’s six LEDs. 


but it’s something we’re used to doing and it makes the display look nice 
and tidy, so why not? 

If you haven’t already done so, launch the main DIY Calculator and 
then invoke the assembler. Use the assembler’s File > Open command to 
access the lab2b.asm file you created in an earlier lab, and then use the 
File > Save As command to rename and save this file as lab2e.asm, which 
should appear as follows: 


CLRCODE: 

• equ 

$10 

# 

Special code to clear the main display 

MAINDISP: 

• equ 

$F031 

# 

Address of output port for main display 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 



Figure L2-20. Flowchart for a program to flash the six LEDs. 











































WRITING TO THE SIX LEDS 


195 


STA [MAINDISP] # Store accumulator to main display 

JMP [$0000] # Jump to address $0000 

•END # This is the end of the program 

In fact we’re going to leave the bulk of this program as is. All we really 
need to do is to declare a new constant called sixleds and assign it to 
the output port at address $F032, and then replace the existing jmp 
(“jump unconditionally”) instruction at the end of the program with the 
new instructions required to implement the flowchart in Figure L2-18 
(the changes are highlighted in gray): 


CLRCODE: 

• EQU 

$10 

# 

Special code to clear the main display 

MAINDISP: 

• EQU 

$F031 

# 

Address of output port for main display 

SIXLEDS: 

• EQU 

$F032 

# 

Address of output port for six LEDs 


.ORG 

$4000 

# 

Set program's origin to address $4000 


LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

Store accumulator to main display 

LOOPA: 

LDA 

$20 

# 

Load accumulator with $20 

LOOPB: 

STA 

[SIXLEDS] 

# 

Store accumulator to six LEDs 


SHR 

JNZ 

JMP 

JMP 


# Shift accumulator 1 bit to the right 
[LOOPB] # Jump to LOOPB if Z flag not set 
[LOOPA] # ..else jump to LOOPA 
[$0000] - tt Jump to address $0000 


.END 


# This is the end of the program 


Everything is familiar until label LOOPA, at which point an LDA (“load 
accumulator”) instruction is used to load the hexadecimal value $20 into 
the accumulator. This value equates to the pattern %00100000 in binary. 
Next, a STA (“store accumulator”) instruction is used to store this value 
to the output port driving the LEDs. As it happens, the front panel has 
been implemented such that an output port bit containing a 1 will turn 
its corresponding LED on, while a 0 will turn it off. Thus, our 
%00100000 value will cause only the left-most LED to be activated. 

Next, a new instruction, SHR (“shift right”), is used to shift the con¬ 
tents of the accumulator one bit to the right. In fact this is a type of shift 
known as an arithmetic shift,^ because the most-significant bit (MSB) in 
the accumulator is copied back into itself, so shifting the %00100000 val¬ 
ue in the accumulator one bit to the right results in its containing a new 
value of %00010000 (Figure L2-21). 


'The “shift” instructions, and their “rotate” cousins, are discussed in more detail in 
Chapters 3 and 4. 
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Figure L2-21. The SHR instruction shifts the contents of the accumulator 
one bit to the right. 


Note that when this shift right is performed, the original contents 
of the least-significant bit (LSB) in the accumulator conceptually “fall off 
the end.” However, this bit is not completely lost to us, because it is 
copied into the C (carry) status flag. We aren’t making any use of this 
aspect of the shift instruction in this program, but it will prove useful in 
the future. 

Following the shift, a JNZ (“jump if not zero”) instruction is used 
to jump to the target location if the contents of the accumulator are 
nonzero. The new value of %00010000 in the accumulator is certainly 
nonzero, so the program will jump back to the label LOOPB, at which 
point it will store this value to the LEDs. Thus, the sequence of values 
that will appear on the LEDs is as shown in Figure L2-22. 



Output port at address 
$F032 (bits 6 & 7 unused) 


iVu'i'i'lT 

X X 1 0 0 0 0 0 
X X 0 1 0 0 0 0 
X X 0 0 1 0 0 0 
X X 0 0 0 1 0 0 
X X 0 0 0 0 1 0 
X X 0 0 0 0 0 1 


Figure L2-22. The patterns appearing on the six LEDs. 
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Now consider what happens after the final value has been written 
to the LEDs. The SHR will cause the %00000001 value in the accumulator 
to be shifted one bit to the right, leaving the accumulator containing 
%00000000. In this case, the JNZ instruction will fail, and the program 
will drop through to the JMP [LOOPA] instruction. This unconditional 
jump returns the program to LOOPA, at which point the accumulator will 
be reloaded with $20 and the whole process will start again. 

To see this work with the real display, assemble the program to 
generate the corresponding lab2e.ram file and then either minimize or 
exit the assembler. Now power-up the calculator and note that, in the 
same way that the main display fills with characters to indicate an 
uninitialized state, all six LEDs power-up in an active condition to indi¬ 
cate that they too are uninitialized. Load the lab2e.ram file we just creat¬ 
ed into the calculator’s memory, and then click the front panel’s Run 
button to execute this new version of our program and observe the activ¬ 
ity on the six LEDs. 

Modifying the System Ciock 

Depending on the power of your home computer, the patterns on your 
LEDs are either crawling along like a lethargic snail or flashing before 
your eyes in a frantic blur (Murphy’s Law^ precludes the third possibility, 
which would be that your display is changing at just the right speed). 

Fortunately, we are prepared for just such an eventuality. Use the 
DIY Calculator’s Setup > System Clock command to invoke the appro¬ 
priate dialog window as shown in Figure L2-23. It should not come as a 
major revelation to discover that clicking the arrows marked Slow and 
Fast followed by the Apply button will cause the system clock to slow 
down or speed up, respectively.^ Note that this doesn’t actually affect the 
speed of your real computer, only the speed of our virtual system. Also 
note that the effects of changing the system clock will persist only for the 
current session; the next time you invoke the calculator, its clock will au¬ 
tomatically be returned to its default setting (which is to go as fast as pos- 

^Murphy’s Law can be summarized as “Anything that can go wrong will go wrong!” This 
was first espoused in a more sophisticated form by Captain Edward A. Murphy in 1949 as 
a useful working assumption in safety-critical engineering. 

^The Apply button applies the new setting and leaves the form on-screen, whereas the 
OK button applies the new setting and then dismisses the form. 
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Figure L2-23. The system clock dialog. 


sible). 

Use this dialog (Figure L2-23) to modify the system clock such that 
the patterns on the LEDs change approximately once per second; that is, 
somewhere around the same rate you’d count “Thousand one, thousand 
two, thousand three. . . .” 

Once you’ve observed that the patterns on the LEDs do indeed 
follow the sequence described earlier, return the system clock to its 
fastest setting, click the OK button to lock in this setting and dismiss 
the dialog window, click the On/Off button to power-down the 
calculator, and proceed to the next, and final (Hurray!), laboratory 
in this section. 

iMsm Purely for the sake of discussion, let’s assume that our 
CPU’s Z (zero) flag isn’t working quite as well as one might hope (per¬ 
haps a cosmic ray knocked it out of action). This means that we don’t 
have any faith in the ability of the JNZ (“jump if not zero”) instruction 
in our program to perform its task as planned. Based on our discus¬ 
sions on the SHR (“shift right”) instruction illustrated in Figure L2-21, 
can you think of another conditional jump we could use to replace 
the JNZ? 
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Using the Memory Walker and 
Other Diagnostic Displays 


Objective: To learn how the Memory Walker, CPU Register, and 

other diagnostic displays can be used to aid in debugging 
programs. 

Duration: Approximately 40 minutes. 


The Need for Diagnostic Tools 

Suppose you create a program, assemble it, run it, and it doesn’t work as 
you expected. How are you going to find out what has gone wrong? In 
fact, there are a variety of different techniques one might use to diagnose 
the cause of the problem, such as single-stepping through the program 
one instruction at a time. There are also a number of different display 
utilities we can use to see what is going on in the CPU’s registers, the 
memory, and the I/O ports. These diagnostic tools and techniques are 
the focus of this laboratory. 

First We Need a 
Demonstration Program 

In order to use the various diagnostic displays supplied with the DIY 
Calculator, we really need a program to play with. We could use one of 
the programs from earlier labs, but we’ve already “been there, done that, 
read the book, sang the song, saw the play, and bought the T-shirt,”^ so 
instead we’re going to create a brand new program that will display the 
message “Hello World” on the calculator’s main display. 



'what? You didn’t get the tattoo? 
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One thing of which we need to be aware before we begin is that the 
CPU contains a special 16-bit register called the “index register,” or “X” 
for short. This register is discussed in more detail in Chapter 3; for our 
purposes here, we need only note that our new program will use the 
index register to provide an offset (“index”) into a series of characters 
(Figure L2-24). (Note that we might also describe this series of characters 
as a string of characters or an array of characters.) 

Purely for the sake of this example, let’s assume that we happen to 
know that the first character in our message is located at memory loca¬ 
tion $4015. If we load the index register with 0 and add this to the start 
address of the message; not surprisingly, we end up with the start address 
again ($4015 -I- 0 = $4015). Obviously this isn’t particularly exciting, but 
if we now increment the index register and add this new value to the start 
address of the message, the result points to the second character in our 
message, and so it goes. As we shall see, this is the basis for our program, 
the flowchart for which is shown in Figure L2-25. 

As usual, this flowchart assumes we are keeping the two instruc¬ 
tions from our earlier programs (shown in white) that are used to clear 
the main display. If you haven’t already done so, launch the main DIY 
Calculator and then invoke the assembler. Use the assembler’s File > 
Open command to access the lab2b.asm file you created in an earlier 
lab, use the File > Save As command to rename and save this file as 
lab2fasm, then edit this file as follows (our new additions are high¬ 
lighted in gray): 


CLRCODE: 

-equ 

$10 

# 

MAINDISP: 

-equ 

$F031 

# 


.ORG 

$4000 

# 


LDA 

CLRCODE 

# 


STA 

[MAINDISP] 

# 


Special code to clear the main display 
Address of main display output port 
Set program's origin to address $4000 
Load accumulator with clear code 
Store accumulator to main display 



-JMP— 

-[$0000] 



Jump to 

addrooo $0000 


BLDX 

0 


# 

Load the 

! index register with 0 

LOOP: 

LDA 

[MESSAGE,X] 

# 

Load accumulator with character 


JZ 

[$0000] 


# 

If 

character = $00 jump to $0000 

STORE: 

STA 

[MAINDISP] 

# 


. else 

write character to display 


INCX 



# 

Increment the index register 


JMP 

[LOOP] 


# 

Jump back to LOOP 

MESSAGE: 

.BYTE 

$48, $45, 

$4C, 

$4C, 

$4F, 

$20 


# 

H E 

L 


L 

0 

SPACE 


.BYTE 

$57, $4F, 

$52, 

$4C, 

$44, 

$00 


# 

W 0 

R 


L 

D 

NUL 


■ END 
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Memory 



$4015 

$4016 

$4017 

$4018 

$4019 


($4015 + 1) 
($4015 + 2) 
($4015 + 3) 
($4015 + 4) 


Figure L2-24. Using the index register to provide an offset into a string of 
characters. 


Before you do anything else, use the assembler’s File > Save command to 
save this file (never fail to take the opportunity to save your work—trust 
us on this if nothing else). Now look at the MESSAGE address label to¬ 
ward the bottom of the program. This is followed by a new directive 
called . BYTE, which instructs the assembler to reserve one or more byte¬ 
wide (8-bit) values. This directive is assigned a series of comma-separat¬ 
ed values, which the assembler will store in adjacent memory locations. 



Figure L2-25. Flowchart for a “Hello World” program. 
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If you cast your mind back to Figure L2-11 in Lab 2c, you will see 
that these values correspond to the ASCII codes for the letters H, E, L, L, 
O, which are followed in turn by the code for a space character. Similar¬ 
ly, the second . byte directive reserves six byte-wide values and fills 
them with the ASCII codes for the letters W, O, R, L, D followed by a $00 
value (which is sometimes referred to as a NUL or NULL). 

Now consider the rest of the program. Everything is reasonably fa¬ 
miliar until the BLDX (“big load of the index register”) instruction. The 
reason this is referred to as a “big load” is that our CPU’s index register is 
16 bits wide (unlike the accumulator which is only 8 bits wide). 

The clever part of this program occurs with the LDA [MESSAGE, X] 
instruction, which uses something called the indexed addressing mode. 
This instructs the assembler to load the accumulator with the contents of 
a memory location whose address is calculated by adding the address of 
the MESSAGE label and the contents of the index register (X). As the in¬ 
dex register currently contains 0, this results in an address of MESSAGE + 
0. This is the first location reserved by the . byte directive, which con¬ 
tains the $48 code corresponding to the letter H. 

Next, a JZ (“jump if zero”) instruction is used to jump to address 
$0000 if the accumulator contains zero. But, as we’ve just discussed, the 
first time around the loop the accumulator contains a value of $48, so 
this test will fail and the program will continue to the STA [MAINDISP] 
instruction. This will write the $48 code in the accumulator to the main 
display, which will now show the letter H. 

This is followed by an INGX (“increment index register”) instruc¬ 
tion, which adds 1 to the current contents of the index register,^ and then 
a JMP (“unconditional jump”) instruction is used to return to the label 
LOOP. This is where things start to get interesting, because the index reg¬ 
ister now contains a value of 1, so this time round the loop the LDA 
[MESSAGE, X] instruction will load the accumulator with the contents 
of the memory location at address message + 1. This is the second 
location reserved by the .BYTE directive, which contains the $45 ASCII 
code for the letter E. 

And so the program proceeds around and around the loop, reading 
the next character from the message and writing it to the calculator’s 
main display. Eventually, the accumulator will be loaded with the $00 

^There is also a corresponding DECX (“decrement index register”) instruction, which 
subtracts 1 from the current contents of the index register. 
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NUL code at the end of the message. This causes the JZ (“jump if zero”) 
instruction to jump to address $0000, at which point the program will 
automatically terminate. 


Introducing the List File 

Assemble the program to generate the corresponding lab2f.ram file. As¬ 
suming no errors were encountered, the assembler automatically gener¬ 
ates another file called lab2f.lst, which is referred to as the list file. Use the 
assembler’s Window > View List File command (or click the corre¬ 
sponding icon on the toolbar), which causes the assembler to display the 
contents of the list file. If you have a printer connected to your system, 
now would be a real good time to generate a hard copy of this file to 
peruse as we proceed. 

When you are presented with your first list file, it may initially seem 
a little complicated, but these little rascals are actually quite easy to read 
once you know the rules. In fact a list file contains three main sections: 
the body of the program and two cross-reference tables. First, let’s con¬ 
sider the body of the program (Figure L2-26). 


LINE 

ADDR 

DATA 

LABEL 

OPCODE 

OPERAND 

00001 





CLRCODE : 

.EQU 

$10 

00002 





MAINDISP : 

.EQU 

$E031 

00003 






.ORG 

$4000 

00004 

4000 

90 

10 



LDA 

CLRCODE 

00005 

4002 

99 

FO 

31 


STA 

[MAINDISP] 

00006 

4005 

AO 

00 

00 


BLDX 

0 

00007 

4008 

92 

40 

15 

LOOP : 

LDA 

[MESSAGE,X] 

00008 

400B 

D1 

00 

00 


JZ 

[$0000] 

00009 

400E 

99 

FO 

31 

STORE: 

STA 

[MAINDISP] 

00010 

4011 

82 




INCX 


00011 

4012 

Cl 

40 

08 


JMP 

[LOOP] 

00012 








00013 

4015 

48 

45 

4 C 

MESSAGE : 

.BYTE 

$48, $45, $4C, 


4018 

4 C 

4F 

20 




00014 








00015 








00016 

401B 

57 

4F 

52 


.BYTE 

$57, $4E, $52, 


401E 

4C 

44 

00 





$4C, $4C, $4F, $20 


$00 


Figure L2-26. Body of the list file for the “Hello World” program. 
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During the process of reading our program (also referred to as the 
source file), the assembler assigns a unique number to each line of source 
code, and these line numbers are displayed in decimal in the left hand 
column. Our original source code is displayed to the right of the list file. 
Thus, the list file shows that our program commenced on line 00001 
when we declared the constant label clrcode and associated it with a 
value of $10. 

Of particular interest is the fact that the machine code relating to 
each line of source code appears between the line number and the orig¬ 
inal source code. The first value to the right of the line number is the 
hexadecimal address of the instruction. Following the address we may 
see one, two, or three hexadecimal values, of which the first value is al¬ 
ways the opcode of the instruction (except in the case of . byte direc¬ 
tives, along with their . 2BYTE and . 4BYTE cousins). On line 00011, 
for example, the JMP instruction is used to jump to label LOOP. This 
instruction occurs at address $4012, the opcode for the JMP instruction 
is $C1, and the two data bytes following the opcode are $40 and $08 
forming address $4008, which is the address associated with the LOOP 


label. 


Following the body of the program is the Constant Labels cross-ref¬ 
erence table, which details the constant labels associated with any . EQU 
directives (Figure L2-27). 



CONSTANT LABELS CROSS -REFERENCE 


NAME 


VALUE LINE NUMBERS WHERE USED (* INDICATES DECLARATION ) 


CLRCODE 00000010 00001 * 00004 
MAINDISP 0000F031 00002* 00005 00009 


ADDRESS LABELS CROSS -REFERENCE 


NAME 


VALUE LINE NUMBERS WHERE USED (* INDICATES DECLARATION ) 


LOOP 

MESSAGE 

STORE 


4008 00007* 00011 

4015 00007 00013 * 

400E 00009* 


Figure L2-27. Cross-reference tables for the “HeUo World” program. 
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Reading this cross-reference table from left to right shows that we 
have a constant label called clrcode with a value of $10. This entry also 
shows that CLRCODE was declared on line 00001 and used on line 00004 
characters are used to indicate the line in which a label is declared). 
Similarly, we have a constant label called maindisp with a value of $F031 
that was declared on line 00002 and used on lines 00005 and 00009. 

Finally, the Address Labels cross-reference table appears at the bot¬ 
tom of the list file. This table shows that the label loop is associated with 
address $4008; it was declared on line 00007 and it is used (referenced) 
on line 00011. Similarly, the label MESSAGE is associated with address 
$4015; it was declared on line 00013 and it is used on line 00007. Last, 
but not least, the label store is associated with address $400E; it was de¬ 
clared on line 00009 and it isn’t actually used anywhere. So, why did we 
declare the label store in our program if we didn’t intend to use it? The 
answer is that this label made the program a tad more readable, and it 
also allows us to quickly locate the address of this instruction in the list 
file. This will prove to be of use shortly; for the moment, however, mini¬ 
mize the assembler to make room on the screen (do not exit it, because 
we’ll be needing it shortly). 


The Memory Walker Display 

Use the main window’s Display > Memory Walker command (or click 
the appropriate icon on the tool bar) to launch the Memory Walker dis¬ 
play, which is used to show the contents of the calculator’s RAM. 


As soon as you invoke one of the utilities such as the Memory Walker, CPU Register, or I/O Ports 
displays, it is recommended that you immediately drag the display (using its blue title bar) away from 
the main calculator front panel and locate it in a clear area of the interface. (You can also resize the Memory 
Walker in a vertical direction so as to make more rows of data visible.) 

The reason we suggest this is that, if you inadvertently chck the front panel when one of the other utilities is 
“on top,” the front panel will “come forward” and may completely obscure the other utility. 

Should this occur, you can drag the calculator front panel around the screen with its blue title bar until you see 
a portion of the hidden display. Clicking on any part of that display will bring it to the foreground, at which 
point you can drag the display to a clear area of the interface. 


Assuming that the calculator hasn’t been powered-up yet, this dis¬ 
play is initially grayed out, indicating that nothing is active, so click the 
On/Off button on the front panel to turn it on. (If the calculator was al- 
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ready running, power it off and on again to return everything to its 
uninitialized state.) 

Applying power causes the Memory Walker display to turn white to 
show that it’s active, but the data column still contains $XX values. These 
indicate that the RAM locations contain random values because they 
haven’t been loaded with anything meaningful yet. 

Now use the Memory -> Load RAM command to locate the 
lablf.ram file we just created and load its contents into the calculator’s 
memory. As you’ll see, this data also appears in the Memory Walker dis¬ 
play (Figure L2-28). 

Compare the values in the Memory Walker display to the contents 
of the address and data columns in the body of the list file (Figure L2-26) 
and convince yourself that they are identical. Now, before you do any¬ 
thing else, glance at the main DIY Calculator’s status bar (at the bottom 
of the window) and observe that it’s indicating the fact that the calcula¬ 
tor is in its reset mode. 

Now click the Run button on the calculator’s front panel to execute 
your program and observe that the main display is cleared, the message 
“HELLO WORLD” appears, and the program terminates and returns the 
calculator to its reset mode. You should also observe that the Memory 



BP 

Step 

Address 

Data 

▲ 




$4000 

$90 

— 1 




$4001 

$10 




$4002 

$99 




$4003 

$F0 




$4004 

$31 




$4005 

$A0 




$4006 

$00 




$4007 

$00 




$4008 

$92 




$4009 

$40 




$400A 

$15 

▼ 


Figure L2-28. The Memory Walker display. 
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Walker became grayed out for a short time. This occurs while the calcu¬ 
lator is in its run mode to indicate that any values being displayed aren’t 
guaranteed to be valid. 

So our program works. Hooray! But what would be our options 
had it failed? One thing we could do is to step through the program one 
instruction at a time. To see how this works, click the Step button on the 
front panel. This causes the calculator to execute the lda instruction at 
address $4000. Observe the chevron characters (“»”) that appear in the 
Memory Walker’s “Step” column pointing to the STA instruction at ad¬ 
dress $4002. Also observe that the status bar at the bottom of the main 
window now indicates that the calculator has entered its step mode. 

When the calculator is in its reset mode, both the Step and Run but¬ 
tons will start by executing whatever instruction is in address $4000, 
which is the first location in the calculator’s RAM. Once the calculator 
has entered its step mode, however, each subsequent click on the Step 
button will cause it to run the next instruction in the program. Similarly, 
if the calculator is in its step mode, clicking the Run button will cause it to 
continue running from its current location in the program. 

Click the Step button again, which causes the calculator to execute 
the STA instruction at address $4002, thereby clearing the calculator’s 
main display. Observe that the chevrons in the Memory Walker now 
point to the BLDX instruction at address $4005. Click the Step button 
again to execute the bldx instruction, click again to execute the JZ in¬ 
struction at address $400B, and click once more to execute the STA in¬ 
struction at address $400E. As we’re currently on the first pass around 
the loop, this writes the first character in our message—the $48 code cor¬ 
responding to the letter H—to the display. 

Once the calculator is in its step mode, it will remain in this mode 
until you click the calculator’s Run or Reset buttons. Keep on clicking 
the Step button until your curiosity is sated, and then click the Run but¬ 
ton, which returns the calculator to its run mode and executes the rest of 
the program. 

Setting and using breakpoints 

Let’s assume we’ve created a program that isn’t exactly working as 
planned and that we’re trying to determine what’s gone wrong. One op¬ 
tion would be to run the program and try to understand what it’s doing 
by puzzling over whatever appears on the calculator’s main display. 
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However, this may not prove to be a particularly useful technique, espe¬ 
cially if the program “crashes-and-burns” in a catastrophic manner. Sim¬ 
ilarly, this approach may falter at the first fence if our program becomes 
locked up, cycling round in a never-ending loop and sitting there not do¬ 
ing much of anything at all. 

As an alternative, we might consider single-stepping through the 
program using the Memory Walker in order to determine exactly what 
the program is doing. The problem here is that, depending on the size of 
our program, we may have to step through hundreds, thousands, or even 
millions of instructions before reaching the point where the problem 
lurks. Yet another option would be to start off by running the program, 
and then dropping back down into the step mode in the vague hope that 
we’ll end up somewhere useful. Strange as it may seem, this tactic occa¬ 
sionally works to our favor, particularly if the problem involves the pro¬ 
gram getting stuck in a loop. Most of the time, however, this approach 
leaves something to be desired. 

One technique that circumvents the above problems is to use one 
or more breakpoints. For the sake of discussion, let’s assume that we want 
to stop our program just before it writes a character to the display. 
Glancing at our trusty list file, we see that this occurs at the STORE label, 
which appears at address $400E. 

Once we’ve determined that $400E is the address of interest, we can 
scroll through the Memory Walker to bring this location into view. Now 
click the breakpoint icon in the Memory Walker’s tool bar. This invokes a 
dialog window that allows us to set or clear breakpoints. Use this dialog 
to specify a breakpoint at address $400E (just key in the “400E”, not the 
“$”) and click the Apply button. The characters “BP” appear in the ap¬ 
propriate box in the Memory Walker’s breakpoint column to indicate 
that a breakpoint has been set. 


The calculator will only honor breakpoints that occur on the first byte (the opcode byte) of an 
instruction. If you try to set breakpoints on operand bytes, the calculator will ignore these “pseudo 
breakpoints” in its frantic desire to reach the next instruction. 


Now click the front panel’s Run button. As usual, the calculator 
starts executing the program at address $4000 and charges merrily ahead 
until it runs headfirst into the breakpoint, at which point it comes to a 
grinding halt and automatically drops down into its step mode. As before. 
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chevrons appear in the Memory Walker to indicate where the calculator 
currently is in the program. If you wanted to, you could now start step¬ 
ping through the program. Alternatively, if you click the Run button 
again, the simulator will reenter its run mode and continue to execute the 
program until it races around the loop and hits the breakpoint again. 

This means that every time you click the Run button, the program will 
write another character to the display and then pause. 

We can use the Memory Walker to sprinkle breakpoints through¬ 
out a program. This means that we can enter the run mode and execute 
the program up to the first breakpoint, single-step for a while as we wish, 
and then click the Run button again to let the calculator proceed to the 
next breakpoint. 

Once we’re happy with the portion of code we’ve been scrutinizing, 
we can use the breakpoint dialog to clear specific breakpoints, or we can 
clear them all in one fell swoop by selecting the Clear All option followed 
by the Apply button. Last but not least, when we power-down the calcu¬ 
lator, it will promptly forget any and all breakpoints from the current 
session (but do not power the calculator down just yet). 

The CPU Register Display 

Another very useful diagnostic tool is the CPU Register display, which 
exposes the contents of the CPU’s internal registers and status flags. 
(Don’t dismiss the Memory Walker just yet, because we will want to 
compare the contents of the two displays side by side.) Access this new 
display using the main window’s Display > CPU Registers command or 
by clicking the appropriate icon on the tool bar (Figure L2-29). 

Click the front panel’s Reset button to ensure that the calculator is in 
its reset mode, and then click the Step button a couple of times and com¬ 
pare what happens in the CPU Register and Memory Walker displays. 

As you’ll see, the Accumulator field displays the current contents of 
the CPU’s 8-bit accumulator while the Index Register field reflects the 
value in the CPU’s 16-bit index register. The Instruction Register field 
shows the opcode of the instruction that is being executed, and the Sta¬ 
tus Register fields display the values of the CPU’s five status flags. (Note 
that “X” values are used to indicate register bits that haven’t been initial¬ 
ized with anything meaningful yet. Values of $XX and $XXXX are associ¬ 
ated with 8-bit and 16-bit registers, respectively.) 
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Accumulator 

$00 


Program Counter- 
$0000 


- Instruction Reg- 

$00 

- Interrupt Vector- 

$XXXX 


Index Register 
$XXXX 


Stack Pointer 
$XXXX 


^ I 


Status Register 


F F F 


[F 


Figure L2-29. The CPU Register display. 


Note especially the Program Counter field. The program counter is 
a 16-bit register the CPU uses to point to whatever instruction is to be 
executed (this register is introduced in more detail in Chapter 3). As you 
will observe, the value in the program counter tracks the location of the 
chevrons in the Memory Walker. 

Working with the CPU Register display takes a bit of practice, but 
once you’ve got the hang of it you will find it to be an incredibly useful 
tool. The main thing to get used to is the fact that the Program Counter 
field is always left pointing at the first byte of the next instruction to be 
executed, whereas aU of the other fields reflect the state of their corre¬ 
sponding registers after the previous instruction was executed. 


The I/O Ports Display 

As you may recall from Lab 2a, addresses $F000 through $F01F in the 
calculator’s memory map are occupied by a set of 32 input ports (of 
which the front panel uses only one port at $F011), whereas addresses 
$F020 through $F03F are occupied by a set of 32 output ports (of which 
the front panel employs only two ports at addresses $F031 and $F032). 

If you wish, you can use the Memory Walker display to see the data 
values currently associated with these ports (the Memory Walker has two 
tool bar icons that take you directly to the input and output ports). 
However, it doesn’t take long to realize that this presentation of the data 
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is not quite as useful as one might hope. As an alternative, we can use an¬ 
other diagnostic tool known as the I/O Ports display. Click the front pan¬ 
el’s Reset button to ensure that the calculator is in its reset mode, and then 
access this new utility via the main window’s Display >1/0 Ports com¬ 
mand or by clicking the appropriate icon on the tool bar (Figure L2-30). 

Starting from the top, the port at address $F031 is the output port 
that drives the calculator’s main display. The various characters and con¬ 
trol codes we can send to the main display were summarized in Figure 
L2-11 in Lab 2c. The left-hand field associated with this item on the I/O 
Ports display reflects the last code written to the port ($41 in this exam¬ 
ple). By comparison, the right-hand field shows the corresponding ASCII 
character or control code name (“A” in this example): 


Code(s) 

$00 through $0F 


$10 

$11 

$12 

$13 through $1F 


$20 


$21 through $7E 
$7F 


Character/string displayed in right-hand field 

“0” through “9” and “A” through “F” 

“Clear” 

“Bell” 


“Back” 


“Space” 

ASCII character 



Figure L2-30. The I/O Ports display. 
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Similarly, in the case of the output port at address $F032 (the port that 
drives the six LEDs on the front panel), the left-hand field associated 
with this item on the I/O Ports display reflects the last code written to 
this port ($2A in this example). By comparison, the right-hand field 
shows the corresponding 0 and 1 binary values being presented to each 
bit (XXIOIOIO in this example, where the two “X” values reflect the 
fact that the most significant two bits in this port aren’t used to drive 
anything). 

Things get a tad more interesting when we come to consider the in¬ 
put port at address $F011 (this is the port we use to see which buttons 
have been pressed on the calculator’s front panel). As we discussed in 
Lab 2d, the front panel has an 8-bit latch that is used to store the code as¬ 
sociated with whichever button was last pressed. Thus, the upper-left- 
hand field associated with this item in the I/O Ports display reflects the 
value that is currently stored in this latch. 

The problem is that the act of reading from this port automatically 
causes the latch to be reloaded with its default value of $FF. Thus, in or¬ 
der to make our lives a little easier, the lower-left-hand field associated 
with this item reflects the value that was previously stored in the latch. 
Meanwhile, the two right-hand fields associated with this port are used 
to display the annotation associated with whichever button has been 
pressed. 

In order to see the I/O Ports display in action, click the front pan¬ 
el’s Step button to execute the lda instruction at address $4000 (this 
loads the clear code of $10 into the accumulator). Now click the Step 
button again to execute the STA instruction at address $4002 (this writes 
the clear code to the calculator’s main display). At this time, the left and 
right fields associated with the output port at $F031 in the I/O Ports dis¬ 
play will show the values $10 and “Clr,” respectively. 

Now try clicking the Log button on the front panel and observe 
what happens on the I/O Ports display. 


The Message System Display 

In addition to the diagnostic tools described above, there’s still one more 
utility, the Message System display, that’s been bashfully hiding in the 
wings, eagerly awaiting its moment of fame. 
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Click the front panel’s Reset button to ensure that the calculator 
in its reset mode, and then access this new utility via the main window’s 
Display > Message System command or by clicking the appropriate icon 
on the tool bar. 

Now click the Step button two or three times to execute the first 
few instructions in the program. As you will see, the Message System 
display provides a wealth of information as to all of the steps that were 
performed during the execution of each instruction (Figure L2-31). 

Observe that the messages in this display have different colors and 
indentations. The left-most text (in black) indicates macroactions, such 
as acquiring an opcode, decoding an opcode, and so on. By compari¬ 
son, the first level of indented text (in blue) reflects microactions, such 
as copying the program counter into the address latch. Finally, the 
second level of indented text (in red) details any additional points of 
interest. 

New messages will be appended to the bottom of this window every 
time you click on the Step button (this display is automatically deactivat¬ 
ed whenever you enter the calculator’s run mode; otherwise you would be 
buried up to your ears in messages). Note that you can use the icons in 


'k'k:k'k'k:k'k'k:k'k 

Get Opcode 

Program counter is $4000 
Program counter -> address latch 
Latch points to target location 
Increment program counter 

Doesn't change address latch 
Read opcode 

Pointed to by address latch 
Opcode = $90 

Opcode -> instruction register 
Decode Opcode 

LDA (load accumulator) [imm] 

Next byte contains data 




Figure L2-31. The Message System display. 
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the Message System display’s tool bar to print and/or clear the current 
contents of the display. 

The String Generator Utility 

Traditionally, creating a routine to write the “Hello World” message to a 
system’s standard output device is the first thing a programmer does to 
verify a new environment. 

A West Coast equivalent to the Hello World program displays the 
message “Hello Sailor!” (this is supposed to have originated at SAIL, 
which stands for the Stanford Artificial Intelligence Lab). 

Use the assembler’s Window > View Source File command (or 
click the corresponding icon on the toolbar) to display the contents of 
our original source file. 

Now use the table in Figure L2-11 from Lab 2c to determine the 
ASCII codes required to upgrade our program to display the “Hello 
Sailor!” message (including the use of uppercase and lowercase charac¬ 
ters and the exclamation mark). Once you have determined the appro¬ 
priate codes, modify our program accordingly and then run it to make 
sure it works. 

In future labs we are going to want to display a lot of different char¬ 
acter strings; for example, we may wish our calculator to display error 
messages along the lines of “You can’t divide a number by zero!” As you 
will no doubt have discovered in generating the “Hello Sailor!” version of 
our program, translating strings into their equivalent ASCII codes by 
hand is a time-consuming and boring process. 

In order to address this issue, the assembler boasts an automatic 
string generator feature. (Good grief! Do you think we should have men¬ 
tioned this before? Oh well, it’s too late now!) In order to see how this 
tool works, we must first delete the two message lines from our original 
program: 













^11, 

^ 1 : , 

^ 1 : , 

^ 1 : , 

^ 1 : , 

•y' ^ U 













^ : 1 , 

^ , 

^ , 

^ , 

^ , 













In the real program, the “$??” values shown here will, of course, be the 
ASCII codes you researched above. Now ensure that the cursor in the as- 
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Figure L2-32. The string generator dialog window. 


sembler’s working area is located at the point where you wish to insert 
your message, and then use the assembler’s Insert > String command to 
access the appropriate dialog window (Figure L2-32). 

Enter MESSAGE into the Message Label field (you can, of course, 
enter any valid label string here; we’re just using MESSAGE to match our 
existing program). Then enter some text such as “Don’t Worry, Be Hap¬ 
py!” into the Message Text field. When you’re ready to proceed, click the 
Convert button and observe the appropriate label, . BYTE directive, and 
associated ASCII codes appear in the Result field. Assuming you are hap¬ 
py with this result, click the Insert button to cause this message to be in¬ 
serted at the cursor’s current location in the source code and then click 
the Exit button to dismiss this dialog. 


The program featured in this lab used two . byte direc¬ 
tives. Were both of these directives necessary, and why didn’t the second 
directive have a label associated with it? 
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Using Logical Instructions, 

Shifts, and Rotates 


Objective: To gain a deeper understanding as to the relationship 

between binary (and hexadecimal) values and ASCII 
characters. Also, to enjoy some “hands-on” experience 
with logical instructions, shifts, and rotates. 

Duration: Approximately 50 minutes. 


Creating a Skeleton ASM File 

We are going to be creating a variety of programs in the following labs, 
which means it will be well worth our time to create a skeleton (frame¬ 
work) assembly file. This will save us from having to type the same things 
over and over and over again, so invoke the assembler and enter the fol¬ 
lowing source code: 

####################################################################### 
## start of constant declarations ## 

####################################################################### 


MAINDISP: 

■ EQU 

$F031 

# 

Address of 

output port for main display 

SIXLEDS: 

■ EQU 

$F032 

# 

Address of 

output port for six LEDs 

KEYPAD: 

■ EQU 

$F011 

# 

Address of 

input port for keypad 

CLRCODE: 

■ EQU 

$10 

# 

Special code to clear the main display 

BINMODE: 

■ EQU 

%00000100 

# 

LED code to 

indicate binary mode 

DECMODE: 

■ EQU 

%00000010 

# 

LED code to 

indicate decimal mode 

HEXMODE: 

■ EQU 

%00000001 

# 

LED code to 

indicate hexadecimal mode 


####################################################################### 
## End of constant declarations ## 

####################################################################### 


■ORG $4000 # Set program origin 

####################################################################### 
## Start of initialization ## 

####################################################################### 
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INIT: 

LDA 

CLRCODE 

# 

Load accumulator with 

clear code 


STA 

[MAINDISP] 

# 

Write clear code to main display 


LDA 

HEXMODE 

# 

Load accumulator with 

hex mode code 


STA 

[SIXLEDS] 

# 

Write to port driving 

six LEDs 


####################################################################### 
## End of initialization ## 

####################################################################### 

####################################################################### 
## Start of main program body ## 

####################################################################### 

####################################################################### 
## End of main program body ## 

####################################################################### 

####################################################################### 
## Start of subroutines ## 

####################################################################### 

####################################################################### 
## End of subroutines ## 

####################################################################### 

####################################################################### 
## Start of global data ## 

####################################################################### 

####################################################################### 
## End of global data ## 

####################################################################### 

.END # That'S all folks 

Now, before you do anything else, use the assembler’s File > Save 
As command to save this file as my-skeleton.asm. Then try assembling 
it to make sure that you didn’t make any errors. Once you are satisfied 
that everything is as it should be, use the assembler’s File > New com¬ 
mand to clear the assembler’s working area, and then proceed to the 
next section. 


Are Your Codes the Same 
as My Codes? 


As we previously discussed in Lab 2d, each of the buttons on the calcula¬ 
tor’s keypad area has an 8-bit code associated with it; these codes are 
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shown as hexadecimal values in parentheses. For example, $16 and $1A 
are the codes associated with the “+” and “=” buttons, respectively 
(Figure L3-1). 

When we click on a button, its associated code is loaded into an 
8-bit latch. The code is stored in this latch until the CPU performs a 
read operation from the input port connected to the latch, at which 
time the latch is reloaded with its default value of $FF. What we are 
going to do is to create a program that loops around, waiting for a key 
to be pressed, and then presents the corresponding code on the main 
display as a dollar sign “$” followed by two hexadecimal digits. For ex¬ 
ample, if we click the “=” button, we want “$1A” to be presented on 
the main display. 

“Aha!” you may be thinking to yourself, “This is going to be easy- 
peasy. All we have to do is read a code from the keypad into the accumu¬ 
lator and then write that code straight back out again to the main dis¬ 
play.” Maybe you have something like the following in mind: 


GETKEY: 

LDA 

[KEYPAD] 


JN 

[GETKEY] 

DISPKEY: 

STA 

[MAINDISP] 


etc. 



# Load ACC with code from keypad 

# Jump back if no key pressed 

# Display code on main display 


ru 


($45) 


($44) 

u 

($43) 

a; 

Bin l\ / 
($42) I 

Dec 

($41) 



Hex 

($40) 


($26) 

($2B) 

($30) 

($35) 

Sin 

($3A) 

x'V 

($3F) 

($25) 

($2A) 

($2F) 

($34) 

Cos 

($39) 

x^3 

($3E) 

($24) 

($29) 

($2E) 

($33) 

Tan 

($38) 

x^2 

($3D) 

($23) 

($28) 

($2D) 

($32) 

Log 

($37) 

Rx 

($3C) 

($22) 

($27) 

($2C) 

($31) 

n! 

($36) 

1/x 

($3B) 


7 

($07) 

8 

($08) 

9 

($09) 

/ 

($19) 

Mod 

($1D) 

Exp 

($21) 

4 

($04) 

5 

($05) 

6 

($06) 

($18) 

Pi 

($1C) 

F-S 

($20) 

($01) 

2 

($02) 

3 

($03) 

($17) 

( 

($1B) 

) 

($1F) 

0 

($00) 

+/- 

($14) 

($15) 

-F 

($16) 

($1A) 

($1E) 

A 

($0A) 

B 

($0B) 

c 

($0C) 

D 

($0D) 

E 

($0E) 

F 

($0F) 




Clear 

CE 

Back i 

Enter 

($10) 
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Figure L3-1. The calculator’s keypad and associated codes. 
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Well, sad to relate, things aren’t quite this simple. Cast your mind back 
to the various character and control codes supported by the main display 
(Figure L3-2). 

Let’s suppose that we are using the program snippet shown above 
and that we click on the upper-right-hand button in the main keypad 
area (the one marked Exp) which will result in the code $21 being loaded 
into the latch. Thus, we want the string “$21” to appear on the main dis¬ 
play. However, if we write the hexadecimal code $21 to the main display, 
from Figure L3-2 we know that the result will be single character: the ex¬ 
clamation mark “!”. 

Now, you will have either been blessed with an immediate under¬ 
standing as to the way in which the keypad and display codes are interre- 
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Figure L3-2. Character codes supported by the main display. 
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lated, or you are currently bouncing back and forth between Figures L3-1 
and L3-2 with a growing feeling of panic. If the latter situation is the case, 
do not despairl It takes most folks a little time to wrap their brains around 
this sort of thing, but once you’ve grasped the underlying concepts you’ll 
find that everything starts to fall into place. 

Let’s consider the code $21 associated with the Exp button from a 
slightly different perspective. From our discussions in Chapters 1 and 2, 
we know that this is an 8-bit value, and that each 4-bit group maps di¬ 
rectly onto a hexadecimal digit (Figure L3-3). 

This means that we actually wish to write three characters (ASCII 
codes) to our main display: first a dollar symbol then the number 
“2,” which corresponds to the most-significant nybble^ in the accumula¬ 
tor (assuming that we’ve read the value from the latch into the accumu¬ 
lator); and, finally, the number “1,” corresponding to the least-signifi¬ 
cant nybble in the accumulator. 

Writing the dollar symbol will be a no-brainer (we just have to 
copy the ASCII code $24 to the main display), but what about the other 
two characters? In the case of the most-significant nybble, we are going 
to have to shift the contents of the accumulator four bits to the right. 

This will result in the accumulator containing a value of $02, which 
will appear as a “2” character when written to the main display [Figure 
L3-4(a)]. By comparison, in order to access the least-significant nybble 
in the accumulator, all we have to do is to clear the four most significant 
bits to 0. This will result in the accumulator containing a value of $01, 
which will appear as a “1” character when written to the main display 
[Figure L3-4(b)]. 

One point we should always remember is that our shr (“shift 
right”) instruction performs an arithmetic shift right, which means that 
every time we perform a shift the most-significant bit in the accumulator 
is copied back into itself Thus, if we were to have a button code whose 
most significant bit were a logic 1, we would have problems if we used 
only the four shift operations shown in Figure L3-4a. 

For example, assuming we had a button code of lOOlOOOlj ($91 in 
hexadecimal), then our four SHR instructions would result in the follow¬ 
ing intermediate results: IIOOIOOO 2 , IIIOOIOO 2 , IIIIOOIO 2 , and 
IIIIIOOI 2 (the four bits shown in bold are the ones we’re interested in). 

'Remember that “nybble” (or “nibble”) is the special name computer weenies use for a 
4-bit group of binary digits, whereas “byte” refers to an 8-bit group. 



226 LABS FOR CHAPTER 3 SUBROUTINES AND OTHER STUFF 


Binary 

Hex 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

0 

0 

1 

0 

2 

0 

0 

1 

1 

3 

0 

1 

0 

0 

4 

0 

1 

0 

1 

5 

0 

1 

1 

0 

6 

0 

1 

1 

1 

7 

1 

0 

0 

0 

8 

1 

0 

0 

1 

9 

1 

0 

1 

0 

A 

1 

0 

1 

1 

B 

1 

1 

0 

0 

C 

1 

1 

0 

1 

D 

1 

1 

1 

0 

E 

1 

1 

1 

1 

F 


Code stored in latch after 
clicking the Exp button 


0 

0 

1 

0 

0 

0 

0 

A 

\ -s / \ ^ / 

1 

2 

16 1 

16 


Figure L3-3. The code associated with the Exp button. 


2i6 

i 


0 0 


Don't Need Don't Need 

i i i 

Original code associated 


1 0 0 


0 0 




stored in accumulator 


0 0 


0 1 0 


0 0 


0 I ◄- SHR 




0 0 


0 0 1 


0 0 


0 I ◄- SHR 




Mask value 
stored in 
memory 


0 0 


0 0 0 


1 0 


0 I ◄- SHR 



<> 


<> 


0 

0 

0 

0 

0 

0 

1 


- SHR 

0 

0 

0 

0 

0 

0 

0 


(a) Extracting the 
most-significant nybble 


(b) Extracting the 
least-significant nybble 


Figure L3-4. Extracting the most- and least-significant nybbles. 
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This means that, following our four shift operations, we would have to 
use an and %00001111 instruction to mask out the four most-signifi¬ 
cant bits and clear them to Os. 

As it happens, none of our button codes has a 1 in the most signifi¬ 
cant bit, so this is never going to be a problem for us. However, it’s good 
practice to get into the habit of thinking about this sort of thing, so we 
will perform this AND operation in our programs anyway. 


Creating the Hex Display Program 

Use the assembler’s File > Open command to access the my-skeleton.asm 
file you created earlier, and then use the File > Save As command to save 
it as lab3a-hex-shr.asm. (If you neglected to build your own skeleton file, 
you can use the one called skeleton.asm that we have already created for 
you.)^ 

Before we do anything else, let’s use a . byte directive to reserve an 
8-bit (1-byte) temporary location called temps in the global data area, as 
shown below: 

####################################################################### 
## Start of global data ## 

####################################################################### 
TEMPS: .BYTE # 8-bit temp location to store data 

####################################################################### 
## End of global data ## 

####################################################################### 

The reason we refer to this area as “global data” is that we intend that 
any of the locations reserved here may be used by any portion of our 
program. As we shall see when we start to create subroutines, in some 
cases we might declare “local data” values as part of a subroutine that are 
intended to be used only by that particular routine. 

Now, let’s create the body of our program as follows (in the future, 
we’ll simply say things like “Add the following statements between the 
Start Body and End Body comments”): 

####################################################################### 
## Start of main program body ## 

####################################################################### 
########## Wait for key to be pressed 

^Oops, did we neglect to mention that before? Sorry! 
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GETKEY: LDA [KEYPAD] # Load ACC with code from keypad 

JN [GETKEY] # Jump back if no key pressed 

STA [TEMPS] # Store key code in temp location 

########## Prepare the main display 

CLRDISP: LDA CLRCODE # Load ACC with clear code 

STA [MAINDISP] # Clear main display 

DISPDOLL: LDA $24 # Load ACC with ASCII code for '$' 

STA [MAINDISP] # Write '$' to main display 

########## Extract and display the most-significant nybble 
DISPMSN: LDA [TEMPS] # Reload ACC with copy of key code 

SHR # Shift right 1 bit (= 1 bit shift) 

SHR # Shift right 1 bit (= 2 bit shift) 

SHR # Shift right 1 bit (= 3 bit shift) 

SHR # Shift right 1 bit (= 4 bit shift) 

AND %00001111 # Clear MS 4 bits {not really necessary) 

STA [MAINDISP] # Copy result to main display 

########## Extract and display the least-significant nybble 
DISPLSN: LDA [TEMPS] # Reload ACC with copy of key code 

AND %00001111 # Mask out (clear) MS nybble 

STA [MAINDISP] # Copy result to main display 

########## Do it all again 

DONE: JMP [GETKEY] # Jump back and wait for new key 

####################################################################### 
## End of main program body ## 

####################################################################### 

The first thing we do (at the GETKEY label) is to loop around, waiting 
for a key to be pressed. As soon as we do get a valid key, we store it 
out into our temporary memory location called TEMP 8. The reason for 
performing this store is that we’re going to be loading other values into 
the accumulator, so we need some way to remember which key was 
pressed. 

Next, we prepare the main display (starting at the CLRDISP label) 
by clearing it and then writing the $24 code for a dollar character (“$”) 
to it. We don’t really need to perform the clear operation in the case of 
the first button we press because we already cleared the main display as 
part of our initialization routine. When we come to process subsequent 
buttons, however, we will want to clear the results associated with the 
previous button from the display. 

When we come to extract and display the most-significant nybble 
(at the DISPMSN label), we start by reloading the key code from our 
temporary location into the accumulator. Then we shift this value four 
bits to the right, mask out the most significant four bits (which isn’t 
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really necessary, but is good practice as we discussed earlier), and write 
the resulting code corresponding to a number character to the main 
display. 

Next, when we come to extract and display the least-significant 
nybble (at the displsn label), we once again reload the key code from 
our temporary location into the accumulator. Then we mask out the 
most significant four bits and write the resulting code corresponding to a 
number character to the main display. 

Finally, we jump back to wait for a new key to be pressed. 

So let’s see if this works. Assemble your program, click the On/Off 
button on the front panel to power-up the calculator, use the Memory > 
Load RAM command to load the lab3a-hex-shr.ram file into the calcula¬ 
tor’s memory and click the Run button to set the program running. Ob¬ 
serve that the light-emitting diode (LED) associated with the Hex legend 
is lit; this is because we stored the hexmode code to the port driving the 
six LEDs as part of our skeleton file’s initialization routine. Now click the 
Exp button on the front panel and the “$21” string will appear on the 
main display. 

Feel free to click some other buttons and ensure that the values ap¬ 
pearing on the main display are as expected. When you’ve finished play¬ 
ing around, click the On/Off button to power-down the calculator and 
scramble its memory again. 


Creating a Binary Display Version 

Now let’s suppose that, as opposed to displaying the key code in hex, we 
decide that we’d prefer to see it in binary. For example, if we press the 
Exp button on the keypad, we’d like to see the string “%00100001” ap¬ 
pear on the main display. Think about how you would go about imple¬ 
menting this for a moment before looking at our solution. 

If you don’t still have the lab3a-hex-shr.asm file open in your as¬ 
sembler, open it now, save it out as lab3a-bin-vl.asm, and then make the 
following changes: 

1) The INIT (initialization) routine currently contains the following 
statement: 


LDA 


HEXMODE 


# Load accumulator with hex mode code 
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Replace this statement with the following: 

LDA BINMODE # Load acchimulator with bin mode code 

Of course, this change is cosmetic (some may say superficial), but its 
all part of the aesthetics of doing things the right way. 

2) The statements associated with the dispdoll label in the main body 
of the program currently read as follows: 

DISPDOLL: LDA $24 # Load ACC with ASCII code for '$' 

STA [MAINDISP] # Write '$' to main display 

Replace these lines with the following: 

DISPPERC: LDA $25 # Load ACC with ASCII code for '%' 

STA [MAINDISP] # Write '%' to main display 

3) Delete all of the statements associated with extracting and displaying 
the most-significant and least-significant nybbles (at the DISPMSN and 
DISPLSN labels, respectively), and replace them with the following: 


########## 

Display 

the binary 

value 

## Process 

bit 

7 




TEST?: 

LDA 


[TEMPS] 

# 

Reload ACC with copy of key code 


SHL 



# 

Shift left 1 bit 


STA 


[TEMPS] 

# 

Store new value in temp location 


JC 


[DISP7_1] 

# 

If carry = 1, jump to display a 1 

DISP7_0: 

LDA 


0 

# 

... otherwise load acc with 0 


STA 


[MAINDISP] 

# 

... and store it to main display 


JMP 


[TESTS] 

# 

... then go and deal with bit 6 

DISP7_1: 

LDA 


1 

# 

Load acc with 1 


STA 


[MAINDISP] 

# 

... and store it to main display 

## Process 

bit 

6 




TESTS: 

LDA 


[TEMPS] 

# 

Reload ACC from temp location 


SHL 



# 

Shift left 1 bit 


STA 


[TEMPS] 

# 

Store new value in temp location 


JC 


[DISP6_1] 

# 

If carry = 1, jump to display a 1 

DISP6_0: 

LDA 


0 

# 

... otherwise load acc with 0 


STA 


[MAINDISP] 

# 

... and store it to main display 


JMP 


[TESTS] 

# 

... then go and deal with bit 5 

DISP6_1: 

LDA 


1 

# 

Load acc with 1 


STA 


[MAINDISP] 

# 

... and store it to main display 

## Process 

bit 

5 




TEST5: 

LDA 


[TEMPS] 

# 

Reload ACC from temp location 


SHL 



# 

Shift left 1 bit 
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STA 


[TEMPS] 

# 


JC 


[DISP5_1] 

# 

DISP5_0: 

LDA 


0 

# 


STA 


[MAINDISP] 

# 


JMP 


[TEST4] 

# 

DISP5_1: 

LDA 


1 

# 


STA 


[MAINDISP] 

# 

## Process 

bit 

4 



TEST4: 

LDA 


[TEMPS] 

# 


SHL 



# 


STA 


[TEMPS] 

# 


JC 


[DISP4_1] 

# 

DISP4_0: 

LDA 


0 

# 


STA 


[MAINDISP] 

# 


JMP 


[TESTS] 

# 

DISP4_1: 

LDA 


1 

# 


STA 


[MAINDISP] 

# 

## Process 

bit 

3 



TEST3: 

LDA 


[TEMPS] 

# 


SHL 



# 


STA 


[TEMPS] 

# 


JC 


[DISP3_1] 

# 

DISP3_0: 

LDA 


0 

# 


STA 


[MAINDISP] 

# 


JMP 


[TEST2] 

# 

DISP3_1: 

LDA 


1 

# 


STA 


[MAINDISP] 

# 

## Process 

bit 

2 



TEST2: 

LDA 


[TEMPS] 

# 


SHL 



# 


STA 


[TEMPS] 

# 


JC 


[DISP2_1] 

# 

DISP2_0: 

LDA 


0 

# 


STA 


[MAINDISP] 

# 


JMP 


[TESTl] 

# 

DISP2_1: 

LDA 


1 

# 


STA 


[MAINDISP] 

# 

## Process 

bit 

1 



TESTl: 

LDA 


[TEMPS] 

# 


SHL 



# 


STA 


[TEMPS] 

# 


JC 


[DISP1_1] 

# 


Store new value in temp location 
If carry = 1, jump to display a 1 
... otherwise load acc with 0 
... and store it to main display 
... then go and deal with bit 4 
Load acc with 1 

... and store it to main display 

Reload ACC from temp location 
Shift left 1 bit 

Store new value in temp location 
If carry = 1, jump to display a 1 
... otherwise load acc with 0 
... and store it to main display 
... then go and deal with bit 3 
Load acc with 1 

... and store it to main display 

Reload ACC from temp location 
Shift left 1 bit 

Store new value in temp location 
If carry = 1, jump to display a 1 
... otherwise load acc with 0 
... and store it to main display 
... then go and deal with bit 2 
Load acc with 1 

... and store it to main display 

Reload ACC from temp location 
Shift left 1 bit 

Store new value in temp location 
If carry = 1, jump to display a 1 
... otherwise load acc with 0 
... and store it to main display 
... then go and deal with bit 1 
Load acc with 1 

... and store it to main display 

Reload ACC from temp location 
Shift left 1 bit 

Store new value in temp location 
If carry = 1, jump to display a 1 
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DISP1_ 

_0: 

LDA 

0 

# 

... Otherwise load acc with 0 



STA 

[MAINDISP] 

# 

... and store it to main display 



JMP 

[TESTO] 

# 

... then go and deal with bit 6 

DISP1_ 

1 : 

LDA 

1 

# 

Load acc with 0 



STA 

[MAINDISP] 

# 

... and store it to main display 

## Process 

bit 0 




TESTO; 


LDA 

[TEMPS] 

# 

Reload ACC from temp location 



SHL 


# 

Shift left 1 bit 



STA 

[TEMPS] 

# 

Store new value in temp location 



JC 

[DISP0_1] 

# 

If carry = 1, jump to display a : 

DISPO. 

_0: 

LDA 

0 

# 

... otherwise load acc with 0 



STA 

[MAINDISP] 

# 

... and store it to main display 



JMP 

[DONE] 

# 

... then go and deal with bit 6 

DISPO. 

1 : 

LDA 

1 

# 

Load acc with 1 



STA 

[MAINDISP] 

# 

... and store it to main display 


This may appear to be a frightening amount of code, but you can 
obviously speed things up by entering the statements associated with one 
of the bits, copying and pasting that block of statements seven more 
times, and then “tweaking” the various labels. (Be careful. This isn’t as 
easy as it might seem, and you are almost bound to make one or more 
mistakes that will take you ages to track down!) 

When you’ve finished entering and assembling (and debugging) the 
above, load the corresponding lab3a-bin-vl.ram file into the calculator 
and ensure that this new version of the program works as planned. 


Additional Exercises 


With regard to our original hexadecimal display program, we used the 
SHR (“shift right”) instruction to shift the most-significant nibble four 
bits to the right. But what if our virtual computer supported only a SHL 
(“shift left”) instruction? Use the assembler to reload the lab3a-hex- 
shr.asm file, save it as lab3a-hex-shl.asm, and modify it to use SHL in¬ 
structions. 

Now, suppose that our virtual computer doesn’t support either the 
SHL or SHR instructions, but only the RORC and ROLC rotate-through- 
carry instructions. Use the assembler to reload the lab3a-hex-shr.asm file, 
save it as lab3a-hex-rorc.asm, and modify it to use RORC instructions. 
Similarly, save a copy called lab3a-hex-rolc.asm, and modify it to use 
ROLC instructions. 
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Finally, with regard to the binary display program, it’s obviously 
painful to have to explicitly code the same tests and display actions for 
each and every bit. It would be much nicer to be able to code the tests 
and display actions a single time, and to then loop around using this 
block of code for each bit in turn. You may recall that in Lab2f we intro¬ 
duced the concept of the index (X) register. Use the assembler to load the 
lab3a-bin-vl.asm file, save it as Iab3a-bin-v2.asm, and then see if you can 
modify this program to use the index register to dramatically reduce the 
amount of code we have to type in.^ 

In the original hexadecimal display program we created 
for this lab {lab3a-hex-shr.asm), we employed the fact that the main dis¬ 
play accepts codes $00 through $0F and uses them to present the hexa¬ 
decimal characters “0” through “9” and “A” through “F.” 

But now let’s suppose that we are presented with a different version 
of the calculator whose main display supports only the standard ASCII 
codes of $20 through $7F. Assuming that we have an ADD instruction 
that allows us to add a value to the current contents of the accumulator, 
how could we modify our original program to achieve the desired result? 


h Answer The solution to this conundrum is based on the fact that 
we know the ASCII codes for “0,” “I,” “2,” . . . are $30, $31, $32, and so 
on; we also know that the ASCII codes for “A,” “B,” “C,” . . . are $41, 
$42, $43, and so on. 

At the end of the existing dispmsn (“display most-significant nyb¬ 
ble”) portion of the program there is a sta [MAINDISP] instruction: 


########## Extract and display the most-significant nybble 


DISPMSN: LDA 

[TEMPS] 

# 

SHR 


# 

SHR 


# 

SHR 


# 

SHR 


# 

AND 

%00001111 

# 

STA 

[MAINDISP] 

# 


Reload ACC with copy of key code 
Shift right 1 bit (= 1 bit shift) 

Shift right 1 bit (= 2 bit shift) 

Shift right 1 bit (= 3 bit shift) 

Shift right 1 bit (= 4 bit shift) 

Clear MS 4 bits (not really necessary) 
Copy result to main display 


This writes a code of $00 through $0F to the main display in the hope 
that the display will treat these codes as representing the hexadecimal 


^In order to make your world a slightly happier place, we’ve included our versions of all 
of the programs described in these labs in the C:\DIYCalculator\Data folder. 
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characters “0” through “9” and “A” through “F.” If we were reduced to 
using only ASCII character codes, then we would have to replace the 
existing STA instruction as follows (modifications are shown highlighted 
in gray): 


########## Extract and display the most-significant nybble 


DISPMSN: LDA 

SHR 
SHR 
SHR 
SHR 
AND 


[TEMPS] # Reload ACC with copy of key code 

# Shift right 1 bit (= 1 bit shift) 

# Shift right 1 bit (= 2 bit shift) 

# Shift right 1 bit (= 3 bit shift) 

# Shift right 1 bit (= 4 bit shift) 

%00001111 # Clear MS 4 bits (not really necessary) 


TEST: 


DISP_0_9 : 

DISP_A_F: 
WRITEMSN: 


STA - [MAIMDISP] —# Copy result to main display 

CMPA $09 # Compare the ACC to $09 

JC [DISP_A_F] # If carry is 1, ACC is bigger than 9 

ADD $30 # Add ASCII code for '0' to ACC 

JMP [WRITEMSN] # Jump to write character 

ADD $41 - $0A # Add ASCII for 'A' minus A (see notes) 

STA [MAINDISP] # Copy result to main display 


XheADD $41 - $0A statement (the second line from the bottom of this code snippet) illustrates the 
fact that we can employ simple expressions in our assembly code. The assembler will automatically perform 
this calculation “on-the-fly” and effectively replace our statement with add $37 (because $41 - $0A = $37). 


In this case, we could have performed the calculation by hand, and simply said add 37, but writing it out in 
this manner will make what we’re doing more understandable when someone reads our program in the future. 


The way this works is as follows. We start with a CMPA (“compare 
accumulator”) instruction that is used to compare the value in the accu¬ 
mulator with $09. If the value in the accumulator is less than or equal to 
this value, then we know that we want to display a number character in 
the range “0” to “9.” Alternatively, if the value in the accumulator is 
greater than $09, then we know that we want to display an alpha charac¬ 
ter in the range “A” to “F.” 

Thus, following the CMPA we have a JC (“jump if carry”) instruc¬ 
tion. This will cause a jump to occur if the value in the carry flag is 1, 
which will be the case if the value in the accumulator is greater than $09. 
So now we have two different scenarios: 

• If the value in the accumulator is less than or equal to $09, we use 
an ADD instruction to add a value of $30 to the accumulator, and 
we then write the result to the main display. Remember that $30 
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is the ASCII code for the “0” character, so if the accumulator 
contains a value of $00, for example, then $00 + $30 = $30, 
which corresponds to the ASCII code for “0”. Similarly, if the ac- 
cumulaor originally contains a value of $01, then $01 + $30 = 
$31, which corresponds to the ASCII code for “1”; and so forth. 

• Alternatively, if the value in the accumulator is greater than $09, 
we use an add instruction to add a value of $41 - $0A to the ac¬ 
cumulator, and we then write this result to the main display. This 
one is a bit trickier to explain, but it’s based on the fact that $41 
is the ASCII code for the “A” character. The problem is that we 
know the accumulator already contains a value between $0A and 
$0F, so we have to take this into account. If the accumulator con¬ 
tains a value of $0A, for example, then $0A -I- $41 - $0A = $41, 
which corresponds to the ASCII code for “A.” Similarly, if the ac¬ 
cumulator originally contains a value of $0B, then $0B -I- $41 - 
$0A = $42, which corresponds to the ASCII code for “B”; and so 
forth. 

Of course, we would also have to perform a similar treatment at the end 
of the existing DISPLSN (“display least-significant nybble”) portion of 
the program. 
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Understanding the 
Program Counter (PC) 


Objective: 


Duration: 


To gain a good understanding as to what the program 
counter is and what it does. 

Approximately 25 minutes. 


An Example Program Snippet 

As we discussed in Chapter 3, the program counter (PC) keeps track of 
where the CPU is in a program, and the contents of the program counter 
are presented to the outside world via the address bus. In order to get a 
feel for exactly what it is that the program counter does, let’s start by 
considering the flowchart associated with a small program snippet as 
shown in Figure L3-5. 



Figure L3-5. Flowchart for example program snippet. 
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This example is fairly meaningless, of course, because it doesn’t 
actually do anything useful, but it will serve to illustrate some of the key 
aspects of the way in which the program counter operates. 

First, we load the accumulator with $00 and then we increment it, 
which means that it now contains $01. Next, we test to see whether or 
not it contains zero, which it doesn’t, so we jump back to increment it 
again. As we keep on cycling around the loop, the accumulator will even¬ 
tually end up containing $FF (or 255 in decimal). This is the largest 
number our 8-bit accumulator can hold, so the next time we perform an 
increment the accumulator will overflow and end up containing $00 
again. At this point, our test will show that the accumulator does indeed 
contain zero, so we’ll drop out of the loop and continue on to the rest of 
the program. 

Now let’s consider the assembly source code we would have to write 
to implement our program snippet. For the purposes of these discussions, 
we’ll terminate our program as soon as we drop out of the loop: 


LOOP: 


ORG 

$4000 

# 

Set program's origin to address $4000 

LDA 

0 

# 

Load accumulator with zero 

INCA 


# 

Increment the accumulator 

JNZ 

[LOOP] 

# 

Jump to LOOP if ACC !=0 

JMP 

[$0000] 

# 

Jump to address $0000 

END 


# 

Terminate the program 


With regard to the comment associated with the JNZ (“jump if 
not zero”) instruction, you may recall from our discussions in Lab 2c 
that the “!” character is often used to indicate an inversion or a nega¬ 
tive (“not”) state, so the string “acc ! = 0” indicates “ACC is not equal 
to zero.” 

Power-up your DIY Calculator, invoke the assembler, key in this 
program, and then use the assembler’s File > Save As command to save 
this file as labSb.asm. 

Assemble the program to generate the corresponding lab3b.ram 
file, and then, assuming no errors were encountered, use the assembler’s 
Window > View List File command (or click the corresponding icon on 
the toolbar) to display the contents of the list file, which should look 
something like the one shown in Figure L3-6. 

Now, just to hammer the point home, let’s consider how the ensu¬ 
ing machine code will end up being loaded into the calculator’s memory 
(Figure L3-7). 
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LINE ADDR 


DATA 


LABEL 


OPCODE OPERAND 


00001 

00002 4000 90 00 
00003 4002 80 
00004 4003 D6 40 02 
00005 4006 Cl 00 00 
00006 


LOOP : 


.ORG 

LDA 

INCA 

JNZ 

JMP 


$4000 

0 

[LOOP] 
[$0000 ] 


Figure L3-6. List file for example program. 


The . ORG directive instructs the assembler to set the origin of the 
program to address $4000. The body of the program commences with 
an LDA (“load accumulator”), which loads the accumulator with zero. 
(Note that lda 0, lda $00, and lda %00000000, with arguments 
specified in decimal, hexadecimal, and binary, respectively, all have ex¬ 
actly the same effect.) Next, the INCA (“increment accumulator”) adds 
1 to the contents of the accumulator. Finally, the JNZ (“jump if not 
zero”) jumps back to the label loop if the contents of the accumulator 
are nonzero. 

So, after loading the accumulator with zero, the program loops 
around, incrementing the accumulator until it contains $FF (that’s 
%11111111 in binary or 255 in decimal). The next time round the loop. 


Assembly source code 


LOOP: 


T 


.ORG $4000 ^ 

LDA 0 - 

INCA -►> 

JNZ [LOOP]- 


Memory 


$4000 

$4001 


$90 

ioft 


$90 = Load the contents of the following 
byte ($00) into the accumulator 


\ $80 = lncrement{add 1 to) the contents of 
J the accumulator. 


etc 



$4003 

$4004 

$4005 


$D6 

$40 

io^ 


$D6 = Jump to the address specified by the 
following two bytes($40 and $02 = $4002) if 
the accumulator doesn't contain zero 


etc. 


Figure L3-7. The machine code in the calculator’s memory. 





















240 


LABS FOR CHAPTER 3 SUBROUTINES AND OTHER STUFF 


the INCA will cause the accumulator to overflow, leaving it containing 
zero. This means that the JNZ will fail (because the accumulator now 
contains zero), and the program will fall through to whatever instruction 
it finds at address $4006. 


Executing the LDA Instruction 

Click the front panel’s On/Off button to power up the calculator and 
then use the main window’s Memory > Load RAM command to load the 
lab3b.ram file into the calculator’s memory. Also, use the main window’s 
Display pull-down menu to activate the Memory Walker, CPU Register, 
and Message System displays. 

Now, click the Step button to execute the first instruction in our 
program. As we were previously in the calculator’s reset mode, this auto¬ 
matically causes the program counter to be loaded with a value of $4000, 
which is used to drive the address bus (Figure L3-8). 

The first thing the CPU does is to read whatever opcode is pointed 
to by the program counter—the lda (“load accumulator”) opcode at ad¬ 
dress $4000, in this case [Figure L3-8(a)]. The CPU stores the opcode in 
an 8-bit register called the instruction register (IR) until it has finished ex¬ 
ecuting this instruction. Following this read operation, the program 
counter is automatically incremented to point to address $4001 
[Figure L3-8(b)]. 

As soon as the CPU examines the $90 opcode from address 
$4000, it recognizes that this is an LDA using the immediate addressing 
mode, so it knows that the next location contains a byte of data. Thus, 
the CPU reads the data at address $4001 and loads it into the accumu¬ 
lator [Figure L3-8(c)]. Furthermore, at the same time as it’s loading 
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Figure L3-8. Executing the LDA instruction. 
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this data into the accumulator, the CPU automatically increments 
the program counter to point to the next opcode at address $4002 
[Figure L3-8(d)]. 

Observe the CPU register display, which shows that the instruction 
register contains the $90 opcode, the accumulator contains the $00 data 
value, and the program counter contains $4002. Also, examine the con¬ 
tents of the Message System window to see all of the macro and micro 
actions that went into executing this instruction. 


Executing the INCA Instruction 

Click the Step button again. The CPU now reads whatever opcode is 
currently pointed to by the program counter—the INCA (“increment 
accumulator”) opcode at address $4002 [Figure L3-9(a)]—and auto¬ 
matically increments the program counter to point to address $4003 
[Figure L3-9(b)]. 

In this case, as soon as the CPU examines the $80 opcode from 
address $4002, it recognizes that this is an INCA using the implied 
addressing mode, so it knows that there isn’t any data associated with 
this instruction. Thus, the CPU executes the inca and immediately 
turns its attention to whatever the program counter is pointing at 
now. 

Observe the CPU register display, which now shows the instruc¬ 
tion register containing the $80 opcode we just executed, the accumu¬ 
lator now contains $01, and the program counter contains $4003. 
Once again, examine the contents of the Message System window to 
see all of the macro and micro actions that went into executing this 
instruction. 
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Figure L3-9. Executing the INCA instruction. 
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Executing the JNZ Instruction 

Click the Step button once more. As usual, the CPU reads whatever op¬ 
code is currently pointed to by the program counter—the JNZ (“jump if 
not zero”) at address $4003 in this case [Figure L3-10(a)]—and auto¬ 
matically increments the program counter to point to address $4004 
[Figure L3-10(b)]. 

When the CPU examines the $D6 opcode from address $4003, it 
recognizes that this is a JNZ using the absolute addressing mode, so it 
knows that the next two locations contain the most-significant and least- 
significant bytes of a target jump address. But the CPU also knows that 
it’s faced with a decision: to jump or not to jump. 

As this is a JNZ, the test will pass and the CPU will jump if the Z 
(zero) flag contains a 0 value, thereby indicating that the accumulator 
contains a nonzero value. Since this is our first time around the loop, the 
accumulator currently contains $01, so we know that the JNZ instruction 
is indeed going to jump. In this case, the CPU will make use of a special 
16-bit register that we can think of as a temporary program counter 
(Temp PC). 
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Figure L3-10. Executing the JNZ instruction. 
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Should you wish to delve deeper, the way in which the CPU executes various instructions is described in 


excruciating detail in the documentation provided on the CD ROM accompanying this copy of How Computers 
Do Math. See the Additional Resources discussions in Appendix D for more details. 


The way to visualize this is that the CPU will read the most-signifi¬ 
cant byte of the target address ($40) from address $4004 [Figure L3- 
10(c)], copy it into the most-significant byte of the temporary program 
counter, and increment the main program counter [Figure L3-10(d)]. 
This means that the temporary program counter now contains $40XX, 
where the “XX” values indicate two as-yet undefined hexadecimal digits. 
Next, the CPU will read the least-significant byte of the target address 
($02) from address $4005 [Figure L3-10(e)] and copy it into the least- 
significant byte of the temporary program counter. Thus, the temporary 
program counter now contains $4002. Last, but not least, the CPU will 
copy the contents of the temporary program counter into the main pro¬ 
gram counter, which effectively causes the CPU to jump back to address 
$4002 [Figure L3-10(f)]. 

Now, let’s assume that we race around the loop again and again un¬ 
til we reach the point where we’ve just incremented the accumulator 
such that it has overflowed and contains $00. Once again, the CPU reads 
the JNZ opcode at address $4003 [Figure L3-10(a)] and increments the 
main program counter to point to address $4004 [L3-10(b)]. 

This time the JNZ test will fail, so the CPU will simply add 2 to the 
contents of the main program counter, leaving it pointing to whatever 
opcode is to be found at address $4006 [Figure L3-10(g)]. 

It’s important to remember that, as discussed in Chapter 3, there 
really isn’t any way for us to control the program counter per se. When 
the CPU is first powered-up, the program counter is initialized with 
some known good value; after this point, the program counter follows 
the dictates of the program itself However, it’s important for us to have 
a good understanding as to how the program counter performs its job, 
because this will help us to appreciate other aspects of the system’s 
machinations when we get to them. 
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Using the Index Register 


Objective: To become familiar with some of the things we can do 

with the index register. 

Duration: Approximately 40 minutes. 

Displaying Button Values in Order 

Before we plunge into the fray, we’re going to need an example program 
to provide a starting point. Use the assembler to open the my- 
skeleton.asm file you created in Lab 3a and save it as lab3c-hex- 
forward.asm. Now add the following statements between the “Start” and 
“End” of the “Main Program Body” comments: 

########## Wait for key to be pressed 


LDA 

[KEYPAD] 

# 

Load ACC from the keypad 

JN 

[GETKEY] 

# 

Jump back if no key pressed 

CMPA 

$0E 

# 

Compare ACC to $0F 

JC 

[GETKEY] 

# 

Jump back if ACC is bigger 

STA 

[MAINDISP] 

# 

. . . else store ACC to display 

JMP 

[GETKEY] 

# 

Go and wait for another key 


This should be more than familiar to us by now. We commence 
with an LDA (“load accumulator”), which loads a value from the keypad. 
If no key has been pressed, the JN (“jump if negative”) causes the CPU to 
jump back to the getkey label. If a key has been pressed, we compare its 
code (the value in the accumulator) to $0F. If the value in the accumula¬ 
tor is larger than $0F, we know that it doesn’t correspond to any of the 
“0” to “9” or “A” to “F” hexadecimal digits. In this case the C (carry) flag 
will be set to 1, so the JC (“jump if carry”) will cause the CPU to jump 
back to the getkey label; otherwise, the test will fail and the STA (“store 
accumulator”) will be used to write the code to the main display. Finally, 
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the JMP (“unconditional jump”) will return us to the GETKEY label in 
order to wait for the next key to be pressed. 

Assemble this program, power-up the calculator, load the lab3c- 
hex-forward.ram program into the calculator’s memory, and run it. Now 
click a few of the hexadecimal number buttons one after the other; for 
example: “2,” “4,” “6,” “8,” “A,” “C,” and “E.” Not surprisingly, we’ll end 
up with the string “2468ACE” on the calculator’s display. 

Displaying Button Values in 
Reverse Order 

Now, suppose that we actually wanted these numbers to be displayed in 
the reverse order from that in which they were pressed. That is, pressing 
“2,” “4,” “6,” “8,” “A,” “C,” and “E” would actually result in “ECA8642” 
appearing on the calculator’s display. How might we achieve this? 

Well, one approach would be to bring the index register into play. 
For example, use the assembler’s File > Save As command to save our 
original lab3c-hex-forward.asm file as lab3c-hex-reverse-x.asm. Now, add 
the following statements between the “Start” and “End” of the “Global 
Data” comments: 

TEMP8: .BYTE # Temp 8-bit (l-byte) location 

TEMP16: .2BYTE # Temp 16-bit (2-bYte) location 

STORE: .BYTE *10 # Reserve 10 x 1-byte locations 

The first of these statements uses a . byte directive to reserve a 1 -byte 
temporary data storage location in the memory; as usual, the address as¬ 
sociated with the TEMP8 label will be that of this byte [Figure L3-11 (a)]. 
The second statement employs a . 2 byte directive to reserve a 2-byte 
location; the address associated with the tempi 6 label will be that of the 
first byte in this field [ Figure L3 -11 (b) ]. The third statement is of 
especial interest, because this is the first time we’ve seen the use of the 
qualifier (in this example, the “*10” instructs the assembler to reserve 
ten 1-byte locations); the address associated with the store label will be 
that of the first byte in this field [Figure L3-11 (c)]. 

At this time, we don’t know precisely where these locations will end 
up in the memory (that will depend on the rest of the program). Howev¬ 
er, if we assume that the temps label is associated with the byte at some 
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(a) TEMP 8 

(b) TEMP 16 

(c) STORE 


Memory 



$nnnn 

$nnnn 

$nnnn 

$nnnn 

$nnnn 

$nnnn 

$nnnn 

etc. 


1 

2 

3 

4 

5 

6 


Figure L3-11. Labels are associated with the first location in their respective 
fields. 


address we might call $nnnn in the memory, then we know that the 
TEMPI 6 label will be associated with the byte at address $nnnn + 1 (the 
first byte in the 2-byte field), whereas the store label will be associated 
with the byte at address $nnnn + 3 (the first byte in the 10-byte field). 

Now modify the body of our program as follows (as usual, changes 
are highlighted in gray): 


########## 

Initialize the index register 

BLDX $0000 # Load index register with zero 

########## 

GETKEY: 

Wait for key to be 

LDA [KEYPAD] 

JN [GETKEY] 

CMPA $0F 

pressed 

# Load ACC from the keypad 

# Jump back if no key pressed 

# Compare ACC to $0F 


JC 

[DISPSTUF] 

# 

Jump if ACC is bigger 


STA 

[STORE,X] 

# 

... else store ACC to memory 


INCX 


# 

... and increment the index reg 


JMP 

[GETKEY] 

# 

Go and wait for another key 

########## 

Display the numbers 



DISPSTUF: 

LDA 

[STORE-1,X] 

# 

Load ACC with a key code 


STA 

[MAINDISP] 

# 

Store it to the main display 


DECX 


# 

Decrement the index register 


JNZ 

[DISPSTUF] 

# 

If index reg not 0 get next code 


JMP 

[$0000] 

# 

Terminate the program 


The first change is that we initialize the index register with zero by 
means of a BLDX (“big load index register”) instruction. As we noted ear¬ 
lier, this is referred to as a “big load” because the index register is 16 bits 
wide (as compared to the accumulator, which is only 8 bits wide). 
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Our GETKEY routine starts off the same way as before, waiting for a 
button to be pressed and then comparing that button’s code with $0F. 
However, in the case of this new version of the program, if the value in 
the accumulator is bigger than $0F (and thus not a hexadecimal digit), 
the JC (“jump if carry”) instruction will cause the program to jump to a 
new routine called dispstue. 

Alternatively, if the value in the accumulator is less than or equal to 
$0F (which means it is a hexadecimal digit), then the JC will fail and the 
program will continue on to the STA [ STORE, X] instruction. This stores 
the value in the accumulator to the memory location whose address is 
calculated by adding the contents of the index register to the address 
associated with the STORE label. 

The first time around the loop, the index register contains 0 [Figure 
L3-12(a)], so this key code wiU be loaded into the first location in our 10- 
byte field [Figure L3-12(b)]. As soon as this code has been stored, the INCX 
(“increment index register”) is used to add 1 to the current contents of the 
index register, which therefore ends up containing 1 [Figure L3-12(c)]. 

The JMP [getkey] instruction then returns us to wait for another 
key to be pressed. Assuming that the next key to be pressed is also a 
hexadecimal digit, this code will be stored in the memory location whose 
address is calculated by adding the contents of the index register to the 
address associated with the store label. But, this second time around 
the loop, the index register contains $0001, so this new key code will be 
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Figure L3-12. One way to view the index register. 
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loaded into the second location in our 10-byte field. Thus, assuming that 
we press the keys “2,” “4,” “6,” “8,” “A,” “C,” and “E,” the result will be 
as shown in Figure L3-12(d). 

Now, let’s assume that the next button we click on the keypad is the 
“Enter” key with a code of $13. In this case, the test associated with the 
JC [dispstuf] instruction will pass, and the CPU will jump to the start 
of the DISPSTUF portion of our program: 


########## 

Display 

the numbers 



DISPSTUF: 

LDA 

[STORE-1,X] 

# 

Load ACC with a key code 


STA 

[MAINDISP] 

# 

Store it to the main display 


DECX 


# 

Decrement the index register 


JNZ 

[DISPSTUF] 

# 

If index reg not 0 get next code 


JMP 

[$0000] 

# 

Terminate the program 


From Figure F3-12(d), we know that adding the address associated with 
the STORE label to the current contents of the index register ends up 
pointing to the first “empty” location in our 10-byte field. Thus, the “-1” 
portion of the LDA [ STORE-1, X] instruction is used to load the accu¬ 
mulator with the contents of the last code (the “$0E” value). 

Once we’ve stored this code to the main display, we use a deck 
(“decrement index register”) instruction to subtract 1 from the current 
contents of the index register. So long as the index register doesn’t contain 
0, the JNZ instruction will jump back to the DISPSTUF label in order to 
display the next code. Finally, when the last code has been written to the 
display and the index register contains 0, the JNZ instruction will fail and 
the program will jump to address $0000, which will cause it to terminate. 

Assemble this new version of our program. Click the Reset button 
on the front panel to ensure the calculator is halted. Use the Memory > 
Purge RAM command to scramble the calculator’s memory. Use the 
Memory > Load RAM command to load our new lab3c-hex-reverse- 
x.ram file. Click the Run button, then press the following keys: “2,” “4,” 
“6,” “8,” “A,” “C,” “E,” and “Enter.” Ensure that the string appearing on 
the main display is as we expect it to be. 

Accessing the Index 
Register’s Contents 

Purely for the sake of discussion, let’s assume that we aren’t bothered 
about displaying the codes associated with the keys at all. What we really 
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wish to know is the value in the index register at the time the first non¬ 
hexadecimal key is pressed. 

First, use the assembler’s File > Save As command to save our 
lab3c-hex-reverse-x.asm file as lab3c-hex-x-contents.asm. The bulk of the 
program can remain as is; all we have to do is to change the six lines as¬ 
sociated with the DISPSTUF portion of the program to read as follows 
(don’t panic, it’s not as frightening as it looks): 


########## 

Display 

the value in the index register 

DISPSTUF: 

BSTX 

[TEMPI6] 

# Store X reg into 2-byte temp location 


LDA 

$24 

# Load ACC with ASCII code for '$' 


STA 

[MAINDISP] 

# Write '$' to main display 

########## 

Extract/display MS 

nybble of MS byte 

DSMSNMSB: 

LDA 

[TEMPI6] 

# Load ACC with MS byte from X reg 


SHR 


# Shift right 1 bit (= 1 bit shift) 


SHR 


# Shift right 1 bit (= 2 bit shift) 


SHR 


# Shift right 1 bit (= 3 bit shift) 


SHR 


# Shift right 1 bit (= 4 bit shift) 


AND 

%00001111 

# Clear MS 4 bits 


STA 

[MAINDISP] 

# Copy result to main display 

########## 

Extract/display LS 

nybble of MS byte 

DSLSNMSB: 

LDA 

[TEMPI6] 

# Reload ACC with MS byte from X reg 


AND 

%00001111 

# Mask out (clear) MS nybble 


STA 

[MAINDISP] 

# Copy result to main display 

########## 

Extract/display MS 

nybble of LS byte 

DSMSNLSB: 

LDA 

[TEMP16+1] 

# Load ACC with LS byte from X reg 


SHR 


# Shift right 1 bit (= 1 bit shift) 


SHR 


# Shift right 1 bit (= 2 bit shift) 


SHR 


# Shift right 1 bit (= 3 bit shift) 


SHR 


# Shift right 1 bit (= 4 bit shift) 


AND 

%00001111 

# Clear MS 4 bits 


STA 

[MAINDISP] 

# Copy result to main display 

########## 

Extract/display LS 

nybble of LS byte 

DSLSNLSB: 

LDA 

[TEMP16+1] 

# Reload ACC with LS byte from X reg 


AND 

%00001111 

# Mask out (clear) MS nybble 


STA 

[MAINDISP] 

# Copy result to main display 


JMP 

[$0000] 

# Terminate the program 


In order to understand what is happening here, let’s assume that 
when we run this new version of the program we are going to click the 
buttons “2,” “4,” “6,” “8,” “A,” “C,” “E,” and “Enter.” In this case, from 




ACCESSING THE INDEX REGISTER'S CONTENTS 


251 


Figure L3-12d we know that, at the time we click the “Enter” button, the 
index register will contain 7. Actually, based on the fact that we know 
that the index register is a 16-bit (2-byte) register, we should really think 
of its contents as being $0007. 

Now, consider what occurs at the start of our new DISPSTUF rou¬ 
tine when we execute the bstx (“big store index register”) instruction to 
store the contents of the index register into the 2-byte location we associ¬ 
ated with the label TEMP16 (Figure L3-13). 

As before, we don’t know precisely where these locations will end 
up in the memory (that will depend on the rest of the program), but, 
purely for the purposes of these discussions, we are assuming that the 
TEMP 8 label is associated with the byte at some address we might call 
$nnnn in the memory, and then referencing aU of the other addresses 
from this point. 

Observe that a copy of the most-significant byte of the index regis¬ 
ter will be loaded into the memory location associated with the TEMPI6 
label. Also notice that a copy of the least-significant byte of the index reg¬ 
ister wiU be loaded into the adjacent memory location. 

The rest of the program is very similar to the lab3a-hex-shr.asm 
program we created in Lab 3a. Fiowever, in this case we wish to display a 
2-byte value in hexadecimal. We commence by writing the ASCII code 
for a dollar (“$”) character to the display. When we come to the DSMSN- 
MSB (“display the most-significant nybble of the most-significant byte”) 
portion of the program, we use its EDA [TEMPI 6] instruction to load a 


TEMP8 
TEMPI 6 


STORE 


$nnnn 

$nnnn 

$nnnn 

$nnnn 

Snnnn 

Snnnn 
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Figure L3-13. The result from the bstx [temp16] instruction. 
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copy of the most significant byte we saved from the index register into 
the accumulator. Then we shift it four bits to the right, clear the four 
most significant bits, and write the resulting code to the display. 

In the case of the dslsnmsb (“display the least-significant nybble 
of the most-significant byte”) portion of the program, we use its lda 
[TEMPI 6] instruction to reload a copy of the most significant byte 
we saved from the index register into the accumulator, and then 
clear the four most significant bits and write the resulting code to the 
display. 

Now we have to repeat the process to display the most- and least- 
significant nybbles from the least-significant byte we saved from the index 
register, which we access using the LDA [TEMP16 + 1 ] instructions. 

Assemble this new version of our program. Click the Reset button 
on the front panel to ensure the calculator is halted. Use the Memory > 
Purge RAM command to scramble its memory. Use the Memory > Load 
RAM command to load our new lab3c-hex-x-contents.ram file. Click the 
Run button. Press the keys “2,” “4,” “6,” “8,” “A,” “C,” “E,” and “Enter,” 
and observe the string “$0007” appear on the main display. 

Using the Index Register as a Counter 

As opposed to using the index register to modify an address when using 
the indexed addressing mode (or the preindexed indirect and indirect 
postindexed modes that we have not yet introduced), this register often 
proves useful as a simple counter. 

As an example, let’s cast our minds back to the lab3a-bin-vl.asm 
program we discussed in the Creating a Binary Display Version section of 
Eab 3a. As you will recall, displaying a button code as eight binary digits 
required a relatively large amount of code. As we shall see, however, we 
can use the index register to dramatically reduce the size of the code and 
make our lives much, much easier. 

Eet’s assume that when any button is pressed on the keypad, we 
wish to display that button’s code as an 8-bit binary value. If the Cos 
button with an associated hexadecimal code of $39 were pressed, for 
example, we would like to see the equivalent binary value “%00111001” 
appear on the main display. 

In order to achieve this goal, use the assembler to open your my- 
skeleton.asm file, save it as lab3c-bin-vl.asm, and then add the following 
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statement between the “Start” and “End” of the “Global Data” 
comments: 

TEMPS: .BYTE # Temp 8-bit (l-byte) location 

Now, add the following statements between the “Start” and “End” of 
the “Main Program Body” comments: 


########## Get and 

display key 

codes in binary 

## Wait 

for a key 

to be pressed 


GETKEY: 

LDA 

[KEYPAD] 

# 

Load ACC from the keypad 


JN 

[GETKEY] 

# 

Jump back if no key pressed 


STA 

[TEMPS] 

# 

Store ACC in temp location 

## Clear 

display then display 

the '%' character 

CLRDISP: 

LDA 

CLRCODE 

# 

Load ACC with clear code 


STA 

[MAINDISP] 

# 

Clear main display 

DISPPERC 

: LDA 

$25 

# 

Load ACC with ASCII code for '%' 


STA 

[MAINDISP] 

# 

Write '%' to main display 

## Initialize index register 



LOADX: 

BLDX 

8 

# 

Load X reg with 8 

## Loop 

around writing 



LOOP: 

LDA 

[TEMPS] 

# 

Reload ACC from temp location 


SHL 


# 

Shift left 1 bit 


STA 

[TEMPS] 

# 

Store new value in temp location 


JC 

[DISP_1] 

# 

If carry = 1, jump to display a 1 

DISP_0: 

LDA 

0 

# 

... otherwise load acc with 0 


STA 

[MAINDISP] 

# 

... and store it to main display 


JMP 

[DEALWX] 

# 

... then go and deal with the X reg 

DISP_1: 

LDA 

1 

# 

Load acc with 1 


STA 

[MAINDISP] 

# 

... and store it to main display 

DEALWX: 

DECX 


# 

Decrement the index register 


JNZ 

[LOOP] 

# 

If X not zero then do next bit 


JMP 

[GETKEY] 

# 

Go back and wait for new key 


This program should be fairly self-explanatory by now. The inter¬ 
esting part starts once we have a new key code (which we’ve stored in the 
TEMP 8 memory location) and we load the index register with a value of 8 
at the LOADX label. 

We then loop around, shifting the value stored in the TEMP8 lo¬ 
cation 1 bit to the left, displaying a corresponding “0” or “1” on the 
main display, and decrementing the index register. We do this eight 
times, once for each bit in the code, until the index register contains 
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zero, at which point we jump back to wait for the next button to be 
pressed. 

As usual, assemble this new program. Click the Reset button on the 
front panel to ensure the calculator is halted. Use the Memory > Purge 
RAM command to scramble its memory. Use the Memory > Load RAM 
command to load our new lab3c-bin-vl.ram file. Click the Run button, 
then press the Cos button and observe the string “%00111001” appear 
on the main display. Now, try clicking some of the other buttons to see 
their binary codes. 


Additional Exercise 


Create a new copy of our last program called Iab3c-bin-v2.asm and modi¬ 
fy it to display a dash between the most-significant and least-significant 
nybbles. For example, pressing the Cos button should result in the string 
“%0011-1001” appearing on the main display. 
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Using the Stack and 
Stack Pointer (SP) 


Objective: To become familiar with some of the things we can do 

with the stack and stack pointer in the context of pushing 
and popping the accumulator. 

Duration: Approximately 25 minutes. 


A Simple Stack-Based Program 

In the previous lab, we used the index register to create a program that 
accepted numbers from the keyboard and displayed them in the reverse 
order to that in which their buttons were pressed. That is, pressing “2,” 
“4,” “6,” “8,” “A,” “C,” and “E” actually resulted in “ECA8642” appear¬ 
ing on the calculator’s display. 

In this lab, we are going to do something very similar, but this time 
we are going to make use of the stack. Use the assembler to open your 
my-skeleton.asm file and save it as lab3d-hex-reverse-sp.asm. Now add the 
following statements between the “Start” and “End” of the “Main Pro¬ 
gram Body” comments: 


########## Initialize the stack pointer 

BLDSP $EFFF # Load Stack pointer with $EFFF 


########## 

Wait for 

key to be 

pressed 

GETKEY: 

NOP 


# 

"No operation" (see notes) 

LOOP: 

LDA 

[KEYPAD] 

# 

Load ACC from the keypad 


JN 

[LOOP] 

# 

Jump back if no key pressed 


CMPA 

$0F 

# 

Compare ACC to $0F 


JC 

[DISPSTUF] 

# 

Jump if ACC is bigger 


PUSHA 


# 

... else push ACC onto the i 


JMP 

[GETKEY] 

# 

Go and wait for another key 
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########## Display a number 

DISPSTUF: POPA # Pop ACC off the stack 

STA [MAINDISP] # Store it to the main display 

JMP [GETKEY] # Go and wait for another key 

This works a tad differently from our previous implementation. We 
commence by loading the stack pointer with $EFFF, which isn’t particu¬ 
larly surprising. What may raise a few eyebrows, however, is the first in¬ 
struction in the GETKEY portion of the program: the NOP (“no opera¬ 
tion”). As its name might suggest, this causes the CPU to do nothing at 
all, really. 

So why might one use a NOP instruction? Well, executing a NOP 
takes the CPU a finite amount of time, which can make it useful for cre¬ 
ating delay loops in a program. In this case, however, we are going to use 
this instruction to facilitate our use of breakpoints when we come to run 
the program (see also the Testing the Program discussions below). 

Following the NOP, we loop around, waiting for a key to be pressed. 
Once a key has been pressed, we compare it to $0F to see if it is a hexa¬ 
decimal character in the range “0” to “9” and “A” to “F” or if it is some 
other key. If it is a hexadecimal character, the JC (“jump if carry”) in¬ 
struction will fail, and the pusha (“push accumulator”) instruction will 
push a copy of the accumulator onto the stack. 

In the case of a nonhexadecimal key, the JC instruction will pass 
and the program will jump to the DISPSTUF portion of the program. 
This uses a popa (“pop accumulator”) instruction to retrieve whatever 
value is on the top of the stack and copy it into the accumulator. Next, 
we use a STA (“store accumulator”) instruction to write this value to the 
main display, and then we jump back to wait for another key to be 
pressed. 

Testing the Program 

Ensure the calculator is powered-up. Assemble our new program (do not 
dismiss the assembler). Click the Reset button on the front panel to en¬ 
sure that the calculator is halted. Use the Memory > Purge RAM com¬ 
mand to scramble its memory, then use the Memory > Load RAM com¬ 
mand to load our new lab3d-hex-reverse-sp.ram file. 

Now, before we actually run the program, return to the assembler 
for a moment and use its Window > View List File command. Scroll 
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down until you reach the getkey portion of our program, which should 
look something like the following: 


00035 

########## 

Wait 

for key 

to be 

pressed 

00036 

400D 

00 



GETKEY: 

NOP 


00037 

400E 

91 

FO 

11 

LOOP: 

LDA 

[KEYPAD] 

00038 

4011 

D9 

40 

OE 


JN 

[LOOP] 

00039 

4014 

60 

OF 



CMPA 

$0F 

00040 

4016 

El 

40 

ID 


JC 

[DISPSTUF] 

00041 

4019 

B2 




PUSHA 

00042 

401A 

Cl 

40 

OD 


JMP 

[GETKEY] 


In the version shown here, the NOP instruction, which occurs on line 
00036 in the source code, is associated with memory location $400D. 
Make a note of the equivalent memory location in your program if it is 
different for any reason (maybe you’ve been adding things to your ver¬ 
sion of our skeleton file). 

Next, use the Display > CPU Registers and Display > Memory 
Walker commands to activate these two debugging tools. Now click the 
Set/Clear Breakpoints icon in the memory walker, enter the $400D ad¬ 
dress value^ (or your equivalent), ensure the Set Breakpoint radio button 
is selected, and click the Apply button to set this breakpoint, which ap¬ 
pears in the Memory Walker display. 

Now click the Run button. This will cause the calculator to run un¬ 
til it hits our breakpoint, at which point we will automatically drop back 
into step mode. Observe the Stack Pointer field in the CPU register dis¬ 
play, which now shows that the stack pointer has been loaded with 
$EFFF [Figure F3-14(a)]. 

Click the Run button again. Now the CPU is looping around, wait¬ 
ing for a key to be pressed, so let’s put it out of its misery and click the 
number “2” on the front panel. The result is that this code is pushed 
onto the top of the stack [Figure F3-14(b)] and the stack pointer is 
decremented to point to the next free location [F3-14(c)]. 

Once again, as soon as the calculator hits our breakpoint, it 
will drop back into the step mode. Once again, observe the Stack 
Pointer field in the CPU register display, which now shows that the 
stack pointer currently contains $FFFE [Figure F3-14(c)]. If you 
wish, you can also scroll down the Memory Walker display to address 


'Just the “400D” part; you don’t need to key in the “$” character. 
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Memory Memory Memory Memory 

$EFF6 
$EFF7 
$EFF8 
$EFF9 
$EFFA 
$EFFB 
$EFFC 
$EFFD 
$EFFE 
$EFFF 
$F000 


(a) Start (b) Push ACC (c) Dec. SP (d) After 7 codes 


Figure L3-14. Pushing values onto the stack. 


SP 


$02 


SP 


$02 


SP 


$0E 

$0C 


$0A 


$08 

$06 


$04 


$02 


SP 


$EFFF and see that our $02 value has indeed been stored in this 
location. 

Repeat the above procedure—clicking the Run button followed by 
one of the calculator buttons—for the keys “4,” “6,” “8,” “A,” “C,” and 
“E.” Each time you hit our breakpoint and drop back into step mode, ob¬ 
serve the CPU Register display and the stack-related locations in the 
Memory Walker. After the last key press, the stack will appear as shown 
in Figure F3-14(d). 

OK, now let’s go in the other direction. Our starting point is as 
shown in Figure F3-15(a). Click the Run button and then click a non¬ 
hexadecimal key, the “=” key, for example, which will result in our to 
jumping to the DISPSTUF portion of our program. The first instruction 
here is the POPA (“pop accumulator”), which causes the stack pointer to 
be incremented to point to the $0E value on the top of the stack [Figure 
F3-15(b)]; this value is then popped off the stack into the accumulator 
[Figure F3-15(c)]. 

Of course, the STA (“store accumulator”) instruction following the 
POPA will cause the $0E value in the accumulator to be written to the cal¬ 
culator’s main display, upon which the hexadecimal digit “E” will ap¬ 
pear. The program will then jump back to the GETKEY label, which will 
cause the calculator to hit our breakpoint and drop back down into step 
mode. 

Repeat the above procedure—clicking the Run button followed by 
a nonhexadecimal button on the calculator two more times. This will re- 
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Figure L3-15. Popping values off the stack. 


suit in the calculator’s main display showing “EGA.” Each time you hit 
our breakpoint and drop back into step mode, observe the CPU Register 
display and the stack-related locations in the Memory Walker. After the 
last key press, the stack will appear as shown in Figure L3-15(d). 

Now try experimenting a little. Perhaps click another hexadecimal 
key and see what happens. Also, what happens if you pop all of the values 
off the stack and then you click another nonhexadecimal key? 


HBBBi What was the advantage of having the NOP (“no opera¬ 
tion”) as the first instruction in the GETKEY portion of the program (and 
how could we have managed without it)? 
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Using Subroutines 


Objective: To create and use a subroutine to display the hex codes 

associated with a number of bytes in memory. 
Duration: Approximately 35 minutes. 


A Blast from the Past 

If you cast your mind back to Lab 3a, you may recall our creating a pro¬ 
gram called lab3a-hex-shr.asm, which we used to take a byte of data and 
display the hexadecimal characters associated with its most-significant 
and least-significant nybbles. 

For example, if our byte contained a value of $3A in hexadecimal 
(or %00111001), we would first isolate the most-significant four bits 
(0011) and write a value of $03 to the main display (which would present 
the character “3”). We would then isolate the least-significant four bits 
(1001) and write a value of $0A to the main display (which would pre¬ 
sent the character “A”). 

Assuming that the byte we wished to process was stored in a tem¬ 
porary memory location called temp; then the code to do this would 
look something like the following: 

########## Extract and display the most-significant nybble 
DISPMSN: LDA [TEMP] # Reload ACC with copy of key code 

SHR # Shift right 1 bit (= 1 bit shift) 

SHR # Shift right 1 bit (= 2 bit shift) 

SHR # Shift right 1 bit {= 3 bit shift) 

SHR # Shift right 1 bit {= 4 bit shift) 

AND %00001111 # Clear MS 4 bits 

STA [MAINDISP] # Copy result to main display 
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########## Extract and display the least-significant nybble 


DISPLSN: 

LDA 

[TEMP] 

# 

Reload ACC with copy of key code 


AND 

%00001111 

# 

Mask out (clear) MS 

nybble 


STA 

[MAINDISP] 

# 

Copy result to main 

display 


The above was perfectly acceptable when we wished to process only a 
single byte, but things became a little trickier in Lab 3c, when we created 
our program lab3c-hex-x-contents.asm. In that case, we wished to process 
two bytes, so we had to replicate all of the statements shown above in or¬ 
der to handle the second byte. But, of course, that was before we knew 
about subroutines. 

Subroutines to the Resoue 

Purely for the sake of these discussions, let’s suppose that we have four 
bytes we wish to process; for example, consider the following statement 
that will reserve four bytes and initialize them with the values shown: 

TEMP: .BYTE $23, $5A, $06, $4C 

Obviously, we don’t want to replicate all of our original “extract and dis¬ 
play” statements four times. Instead, it will be much more advantageous 
for us to create a subroutine and to call this four times. 

Let’s start by using the assembler to open your my-skeleton.asm file, 
save it as lah3e-suh.asm, and then insert the temp line shown above be¬ 
tween the “Start Global Data” and “End Global Data” comments. 

Next, we need to use a bldsp (“big load stack pointer”) instruction 
to initialize the stack pointer. In order to do this, add the line highlighted 
in gray to the end of the existing initialization instructions as follows: 

####################################################################### 

## Start of initialization ## 

####################################################################### 

INIT: LDA CLRCODE # Load accumulator with clear code 

STA [MAINDISP] # Write clear code to main display 

LDA HEXMODE # Load accumulator with hex mode code 

STA [SIXLEDS] # Write to port driving six LEDs 

BLDSP $EFFF # Load Stack pointer with $EFFF 

####################################################################### 

## End of initialization ## 

####################################################################### 

Now, enter the following routine between the “Start Subroutine” and 
“End Subroutine” comments: 
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########## Subroutine to extract/display MS and LS nybbles of byte 
DISPBYTE: PUSHA # Push a copy of ACC onto stack 


########## Extract and display the most-significant nybble 
DISPMSN: SHR # Shift right 1 bit {= 1 bit shift) 

SHR # Shift right 1 bit (= 2 bit shift) 

SHR # Shift right 1 bit (= 3 bit shift) 

SHR # Shift right 1 bit (= 4 bit shift) 

AND %00001111 # Clear MS 4 bits 

STA [MAINDISP] # Copy result to main display 


########## Extract 
DISPLSN: POPA 

AND 
STA 
RTS 


and display the least-significant nybble 

# Pop copy of original byte off stack 

%00001111 # Mask out (clear) MS nybble 

[MAINDISP] # Copy result to main display 

# Return from subroutine 


A key point about this subroutine is that, when we enter it, it as¬ 
sumes that the byte we wish to display is already in the accumulator. 
Thus, the first thing we do is to push a copy of the accumulator onto the 
stack for later use. We next extract and display the most-significant nyb¬ 
ble; this process loses any bits associated with the least-significant nybble, 
so we pop our copy of the original value back off the stack and then ex¬ 
tract and display the least-significant nybble. 

Finally, add the following lines of code between the “Start Body” 


and “End Body” 

comments: 




LDA 

[TEMP] 

# 

Load 

1st byte into ACC 

JSR 

[DISPBYTE] 

# 

Call 

display byte subroutine 

LDA 

[TEMP+1] 

# 

Load 

2nd byte into ACC 

JSR 

[DISPBYTE] 

# 

Call 

display byte subroutine 

LDA 

[TEMP+2] 

# 

Load 

3rd byte into ACC 

JSR 

[DISPBYTE] 

# 

Call 

display byte subroutine 

LDA 

[TEMP+3] 

# 

Load 

4th byte into ACC 

JSR 

[DISPBYTE] 

# 

Call 

display byte subroutine 

JMP 

[$0000] 

# 

Terminate the program 


In the case of this particular example, for each of the bytes to be dis¬ 
played, we first load that byte into the accumulator and then call our 
DISPBYTE subroutine. 


Testing the Basic Subroutine 

Ensure that the calculator is powered-up. Assemble our new program. 
Click the Reset button on the front panel to ensure that the calculator is 
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halted. Use the Memory > Purge RAM command to scramble its 
memory, then use the Memory > Load RAM command to load our new 
lab3e-sub.ram file. 

Now, click the Run button to execute this program and observe the 
character string that appears on the main display: “235A064C.” 


Creating a Nested Version 

One point worth noting about the subroutine we just created is that it 
extracted and displayed both the most-significant and least significant 
nybbles. As an alternative, we might decide to create a nested version. 
First, use the assembler to save a copy of our lab3e-sub.asm program with 
the new name of lab3e-nested.asm. Now replace the original version of 
our DISPBYTE subroutine with the following: 


########## 

DISPBYTE: 


Subroutine to extract/display MS and LS nybbles of byte 


PUSHA 

JSR [DISPMSN] 

POPA 

JSR [DISPLSN] 

RTS 


# Push a copy of ACC onto stack 

# Call sub for MS nybble 

# Pop copy of original byte off stack 

# Call sub for LS nybble 

# Return to calling location 


########## Subroutine to extract/display the MS nybble 


DISPMSN: 

SHR 



SHR 



SHR 



SHR 



AND 

%00001111 


STA 

[MAINDISP] 


RTS 



# Shift right 1 bit {= 1 bit shift) 

# Shift right 1 bit (= 2 bit shift) 

# Shift right 1 bit (= 3 bit shift) 

# Shift right 1 bit (= 4 bit shift) 

# Clear MS 4 bits 

# Copy result to main display 

# Return to calling location 


########## Subroutine to extract/display the LS nybble 
DISPLSN: AND %00001111 # Mask out (clear) MS nybble 

STA [MAINDISP] # Copy result to main display 

RTS # Return to calling location 


As we see, dispbyte, dispmsn, and displsn are all subroutines in 
their own right. In this case, the body of our program still calls the 
DISPBYTE subroutine, which in turn calls DISPMSN and DISPLSN as 
nested subroutines. 
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Testing the Nested Version 

Ensure that the calculator is powered-up. Assemble our new program. 
Click the Reset button on the front panel to ensure that the calculator is 
halted. Use the Memory > Purge RAM command to scramble its memo¬ 
ry, then use the Memory > Load RAM command to load our new lab3e- 
nested.ram file. 

Now, click the Run button to execute this program and, once again, 
observe the string of characters that appears on the main display: 
“235A064C.” 

Why Create the Nested Version? 

One question you may be asking yourself is: “Why would we bother to 
create the nested version of our original subroutine?” After all, the two 
renderings generate the same results, and the nested incarnation required 
a few more lines of code (which, in this particular example, means it oc¬ 
cupies more memory and takes longer to run). 

Well, this is only a very simple subroutine but, generally speaking, 
it’s better to break things down into smaller “chunks,” because these 
smaller blocks of code are easier to debug and understand. Furthermore, 
we can now use the various “chunks” in their own right. For example, if 
we wished to see both nybbles from the first and second bytes, but only 
the most-significant nybble from the third byte and only the least signifi¬ 
cant nybble from the fourth byte, then we could achieve this with our 
nested implementation by modifying the body of the program as follows: 


LDA 

[TEMP] 

# 

Load 1st byte into ACC 

JSR 

[DISPBYTE] 

# 

Display MS and LS nybbles 

LDA 

[TEMP+1] 

# 

Load 2nd byte into ACC 

JSR 

[DISPBYTE] 

# 

Display MS and LS nybbles 

LDA 

[TEMP+2] 

# 

Load 3rd byte into ACC 

JSR 

[DISPMSN] 

# 

Display MS nybble only 

LDA 

[TEMP+3] 

# 

Load 4th byte into ACC 

JSR 

[DISPLSN] 

# 

Display LS nybble only 

JMP 

[$0000] 

# 

Terminate the program 
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Recursive Subroutines 


Objective: To create a recursive subroutine that displays a string of 

characters in reverse order. 

Duration: Approximately 40 minutes. 

Creating the Subroutine 

As we noted in Chapter 3, recursion can be mind-bogglingly complicat¬ 
ed, and it’s usually a lot easier to use a more standard alternative such as 
creating a simple loop that uses a variable as a counter. Purely for the 
sake of providing an example, however, we are going to create a recursive 
subroutine and then try to wrap our brains around its multifarious 
machinations. 

Use the assembler to open the my-skeleton.asm file you created ear¬ 
lier, save it as lab3f-reverse.asm, and then insert the following statements 
between the “Start Global Data” and “End Global Data” comments: 

PHRASE: .BYTE $53, $57, $41, $50, $20 

# SWAP SPACE 

.BYTE $50, $41, $57, $53, $00 

# PAWS NUL 

Together, these form the string “SWAP PAWS” terminated by a 
NUL ($00) character. You can use the assembler’s Insert > String com¬ 
mand to create these statements if you wish; just remember to place the 
cursor where you want them to appear in your source code before you in¬ 
voke the command. 

The body of our program is very simple because it comprises only 
four instructions, which you should insert between the “Start Body” and 
“End Body” comments: 
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BLDX 

0 

# 

Load index register with 0 


BLDSP 

$EFFF 

# 

Load stack pointer with $EFFF 

OUTSIDE: 

JSR 

[REVERSE] 

# 

Call the subroutine 

FINISH: 

JMP 

[$0000] 

# 

Terminate the program 


As we see, the only actions this program performs are to load the index 
register with zero, initialize the stack pointer to point to memory loca¬ 
tion $EFFF, call a subroutine called reverse, and then jump to address 
$0000, which will cause the program to automatically terminate. Note 
that the outside and finish labels are included only to provide points 
of reference for our future discussions. 

Now, enter the following subroutine between the “Start Subrou¬ 
tine” and “End Subroutine” comments: 


########## 
REVERSE: 

RETURNl: 


Recursive subroutine to display string in reverse order 
LDA [PHRASE,X] # Load ACC with a character 

JNZ [COIN] # If it's not NUL jump to COIN 

RTS # Otherwise return from subroutine 


########## Store the character on the stack and go further in 
COIN: PUSHA # Push the character onto the stack 

INCX # Increment the index register 

INSIDE: JSR [REVERSE] # The subroutine calls itself recursively 


########## 
COMEOUT: 

RETURN2: 


Retrieve and display a character and come out 
POPA # Pop a character off the stack 

STA [MAINDISP] # Copy to main display 

RTS # Return from subroutine 


Observe that this routine is a good example of one that uses multiple 
RTS (“return from subroutine”) statements. 


Boggling the Mind 

Now, prepare to have your mind well and truly boggled. Fet’s walk 
through our program and ponder what happens on the stack. Assume 
that the program is at label OUTSIDE and that it’s just about to execute 
the JSR (“jump to subroutine”) instruction, which means that the stack 
is currently empty. 

When the program executes this JSR, the least-significant (FS) and 
most-significant (MS) bytes of the return address (the address of the 
memory location associated with the einish label) will be pushed onto 
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the stack [Figure L3-16(a)], and the program counter will be left point¬ 
ing at the first instruction in the subroutine at the REVERSE label. 

The first thing our subroutine does is to load the accumulator using 
the indexed addressing mode; that is, to load the value (an ASCII charac¬ 
ter in this case) from the memory location whose address is calculated by 
adding the address associated with the phrase label and the current 
contents of the index register (which are $0000). This will be the first $53 
data value (the ASCII letter “S”). 

Next, the JNZ (“jump if not zero”) instruction is used to test for a 
NUL ($00) character. As the accumulator currently contains $53, this test 
will pass, and the program will jump to the GOIN (“go further in”) label. 
[Observe that even if we had had an empty string containing only a NUL 
($00) code, our program would still work in that it would immediately 
return to the main body of the program. It’s very important to consider 
these “corner case” situations when creating a program.] 

When the program arrives at the GOIN label, it uses a PUSHA 
(“push accumulator”) to push a copy of the $53 value onto the stack 
[Figure L3-16(b)]. The program then uses an INCX (“increment index 
register”) instruction followed by the JSR (“jump to subroutine”) at the 
INSIDE label. This is the point where the subroutine becomes recursive, 
because it has just called itself 

When the program executes this JSR at the INSIDE label, the least- 
significant (LS) and most-significant (MS) bytes of the return address 
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Figure L3-16. The stack during the first few instructions. 
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(the address of the memory location associated with the COMEOUT label) 
will be pushed onto the stack [Figure L3-16(c)], and the program 
counter will, once again, be left pointing at the first instruction in the 
subroutine. 

As before, the subroutine loads the accumulator with the character 
from the memory location whose address is calculated by adding the ad¬ 
dress associated with the phrase label and the current contents of the 
index register (which are now $0001). This will be the first $57 data value 
(the ASCII letter “W”). 

The JNZ (“jump if not zero”) instruction now tests for a NUL ($00) 
character. As the accumulator currently contains $57, this test will pass, 
and the program will again jump to the COIN (“go further in”) label. 
Once again, the program uses the PUSHA (“push accumulator”) to push 
a copy of the $57 value onto the stack [Figure L3-17(a)]. 

And, once again, the program uses an INCX (“increment index reg¬ 
ister”) instruction followed by the JSR (“jump to subroutine”) at the 
INSIDE label, which causes the least-significant (LS) and most-signifi¬ 
cant (MS) bytes of the return address (the address of the memory loca¬ 
tion associated with the COMEOUT label) to be pushed onto the stack 
[Figure L3-17(b)]. 

Thus, until we reach a NUL, the subroutine will keep on getting 
character codes, pushing them onto the stack and calling itself. Now let’s 
assume that our subroutine has pushed the final character in our phrase 
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Figure L3-17. The stack during the first few instructions (continued). 
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onto the stack and has just called itself for the last time. This means that 
the index register currently contains $0009 and the top of the stack ap¬ 
pears as shown in Figure L3-18(a). 

As usual, the subroutine loads the accumulator with the character 
from the memory location whose address is calculated by adding the ad¬ 
dress associated with the phrase label and the current contents of the 
index register (which are now $0009). This will be the NUL data value 
(the “$00” code). 

Thus, this time round, the JNZ (“jump if not zero”) instruction 
fails and the program drops through to the next instruction, which is the 
RTS (“return from subroutine”) at the RETURNl label. This causes the 
top two bytes (forming the address associated with the COMEOUT label) 
to be popped off the stack and loaded into the program counter 
[Figure L3-18(b)]. 

When the program arrives at the COMEOUT label, it uses a POPA 
(“pop accumulator”) to retrieve the data value—the last character we 
read—from the top of the stack (Figure L3-18c). This is followed by a 
STA (“store accumulator”) that copies this value to the calculator’s main 
display. The program then executes the RTS (“return from subroutine”) 
at the RETUR]Nr2 label. As usual, this causes the top two bytes (forming 
the address associated with the COMEOUT label) to be popped off the 
stack and loaded into the program counter. 

From this point on, the program simply keeps on popping charac¬ 
ters off the stack at the COMEOUT label, copying them to the main display. 
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Figure L3-18. The stack after the last valid character has been read. 
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and then performing the RTS at the RETURi\[2 label. This RTS keeps on 
returning the program to the COMEOUT label until we’ve processed the fi¬ 
nal character, at which point the final return address stored on the stack 
is that associated with the finish label in the main body of the program 
[Figure L3-16(a)]. 


Testing the Subroutine 

Ensure that the calculator is powered-up. Assemble our new program. 
Click the Reset button on the front panel to ensure that the calculator 
is halted. Use the Memory > Purge RAM command to scramble its 
memory, then use the Memory > Load RAM command to load our new 
lab3f-reverse.ram file. 

Remember that our original character string was “SWAP PAWS” 
and that our recursive subroutine is going to display these characters in 
reverse. Click the Run button to execute the program and observe the re¬ 
versed character string appear on the main display. 

But wait, the string on the display is “SWAP PAWS” again. How 
can this be? Did the program fail to work as planned? In fact, the pro¬ 
gram did perform its task as we described. The problem is that the 
“SWAP PAWS” string is a palindrome (from the Greek palindromos, 
meaning “running back again”), which means that it reads the same for¬ 
ward or backward (sorry, we couldn’t help ourselves). 

Let’s try again. Replace the space ($20) code associated with the 
PHRASE label with a NUL ($00) code as follows (the change is highlighted 
in gray): 

PHRASE: .BYTE $53, $44, $41, $50, $00 

# SWAP NUL 

Assemble this new version of the program, load it into the calculator, run 
it, and observe that the original “SWAP” string is now displayed in re¬ 
verse as “PAWS.” 


A Further Exercise 

Do you feel confident that you know how recursion works now? Yes? 
Well, let’s put that to the test, shall we? In Chapter 3 we mentioned that 
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the canonical example of a recursive function is a factorial. Consider the 


following factorials from 1 to 5: 

Result 

Result 

Factorial 

Expanded 

Decimal 

Hexadecimal 

1! 

= 1 

= 1 

= $01 

2! 

= 2x1 

= 2 

= $02 

3! 

= 3x2x1 

= 6 

= $06 

4! 

=4x3x2xl 

= 24 

= $18 

5! 

=5x4x3x2xl 

= 120 

= $78 


That’s as far as we care to go at the moment, because the next factorial 
(6! = 720) would be too large to store in a single byte (as we know from 
Chapter 1, an 8-bit byte can be used to represent positive integers in the 
range 0 to 255). 

For your delectation and delight, we’ve precreated a special subrou¬ 
tine called FMULT (“factorial multiplier”). Don’t worry about how this 
routine performs its magic, because we’ll be covering that in Chapter 4. 
All we need to know at the moment is that when this subroutine is called, 
it takes the first two bytes it finds on the top of the stack, multiplies them 
together, and leaves a single result byte on the top of the stack. ^ 

For example, assume that the two bytes on the top of the stack con¬ 
tain $03 and $02 as shown in Figure L3-19(a). If we were to call fmult at 
this point, then after this subroutine had completed its task and returned 
control to the main program, the new value on the top of the stack 
would be $06, as shown in Figure L3-19(b). 

Your mission, should you decide to accept it, is to use the assembler 
to open up your my-skeleton.asm file and save it as lab3f-factorial.asm. 
Next, place the cursor between the Start Subroutine and End Subroutine 
comments and then use the assembler’s Insert > Insert File command to 
insert our FMULT subroutine (you’ll find this routing in the C:\DlYCal- 
culator\Work folder). 

'As we’ll see in Chapter 4, when two binary numbers are multiplied together, the width 
of the result is equal to the sum of the bits forming the multiplicand and multiplier. 

Thus, multiplying two 1-byte values together will return a 2-byte result. For the purposes 
of this application, however, in which we know the result will never be greater than 255, 
our FMULT routine discards the most-significant byte of the result and returns only the 
least-significant byte. 



274 


LABS FOR CHAPTER 3 SUBROUTINES AND OTHER STUFF 



Memory 
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(a) Before calling fmult (b) After calling fmult 

Figure L3-19. Example stack contents before and after calling the fmult 
subroutine. 


Now, we want you to create a program that loops around, waiting 
for a button to be pressed in the range “1” to “5” (any other button 
should be ignored). When a button in the range “1” to “5” is pressed, 
your program should call a subroutine called FACTOR, which you are go¬ 
ing to create. This subroutine will call itself recursively in order to calcu¬ 
late the factorial associated with the button you pressed. Note that this 
subroutine can call our FMULT routine whenever it wishes to multiply 
two numbers together. 

Once you have calculated the factorial, you can use a version of the 
DISPBYTE subroutine we created in Lab 3e to display the resulting byte 
in hexadecimal on the calculator’s main display. Last but not least, return 
to the beginning of the program and wait for another button to be 
pressed. 

Once you’ve created this program, assemble it, load it into the cal¬ 
culator, run it, and check that it generates the correct results (as shown 
in the table at the beginning of this section). 
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Lab 


Objective: To create a testbench program that can be used to input a 

pair of hexadecimal values, call a 16-bit integer math 
subroutine, and display the result. 

Duration: Approximately 30 minutes. 


Creating the Testbench Program 

The majority of labs associated with Chapter 4 involve subroutines that 
perform some task, such as addition, subtraction, multiplication, or divi¬ 
sion, on a pair of 16-bit numbers. So the first thing we are going to do is 
to create a testbench program that can read in two 16-bit hexadecimal 
values and place them on the stack, call one of our math subroutines 
(which we will be developing in subsequent labs), and display the result. 

Copy your original skeleton routine 

First of all, invoke the assembler, load the original my-skeleton.asm file 
that you created in Lab 3a, and save it as skeleton-lab4.asm. Unless some¬ 
thing totally weird has happened to the space-time continuum as we 
know it, this file should appear something like the following: 

####################################################################### 
## Start of constant declarations ## 

####################################################################### 
MAINDISP: .EQU $F031 # Address of out port for main display 

SIXLEDS: -EQU $F032 # Address of out port for six LEDs 

KEYPAD: -EQU $F011 # Address of input port for keypad 

CLRCODE: .EQU $10 # Special code to clear main display 

BINMODE: -EQU %00000100 # LED code to indicate binary mode 

DECMODE: -EQU %00000010 # LED code to indicate decimal mode 

.EQU %00000001 # LED code to indicate hexadecimal mode 



01000010101101010010010010001101100000EIEEE 

Creating a Testbench Program 


HEXMODE 
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####################################################################### 
## End of constant declarations ## 

####################################################################### 

■ORG $4000 # Set program origin 

####################################################################### 
## Start of initialization ## 

####################################################################### 
INIT: LDA CLRCODE # Load accumulator with clear code 

STA [MAINDISP] # and write it to the main display 

LDA HEXMODE # Load accumulator with hex mode code 

STA [SIXLEDS] # and write it to port driving LEDs 

####################################################################### 
## End of initialization ## 

####################################################################### 

####################################################################### 
## Start of main program body ## 

####################################################################### 

####################################################################### 
## End of main program body ## 

####################################################################### 

####################################################################### 
## Start of subroutines ## 

####################################################################### 

####################################################################### 
## End of subroutines ## 

####################################################################### 

####################################################################### 
## Start of global data ## 

####################################################################### 

####################################################################### 
## End of global data ## 

####################################################################### 

.END # That'S all folks 

Modifying the initialization routine 

First, let’s modify the initialization portion of this file to load the stack 
pointer (SP) with an initial value of $EFFF (the new statement is shown 
highlighted in gray): 



CREATING THE TESTBENCH PROGRAM 279 


INIT: 


LDA CLRCODE # Load accumulator with clear code 

STA [MAINDISP] # Write clear code to main display 

LDA HEXMODE # Load accumulator with hex mode code 

STA [SIXLEDS] # Write to port driving six LEDs 

BLDSP $EFFF # Load Stack pointer with initial value 


Now, use the assembler’s File > Save command to save this change. (The 
moral here is that you should never fail to take an opportunity to save 
your work. You’ll come to understand our paranoia in the fullness of 
time.) 


Reserving global temporary data locations 
and messages 

Next, we’ll reserve some locations in which to store temporary address 
and data values as required, along with any message strings. Let’s start by 
adding the following statements between the “Start” and “End of Global 
Data” comments. 


INSTRING: 

.BYTE * 

10 

# 

Reserve 

10 

bytes 

to store a string 

TMPBYTE: 

.BYTE 


# 

Reserve 

a 

l-byte 

temp 

location 

TMP2BYTE: 

.2BYTE 


# 

Reserve 

a 

2-byte 

temp 

location 

TMP4BYTE: 

. 4BYTE 


# 

Reserve 

a 

4-byte 

temp 

location 

########## 

Start 

of message 

strings 






Now, place your cursor at the beginning of the blank line following 
the “Start of message strings” comment; then use the assembler’s Insert > 
String command to access its associated dialog window and use this tool to 
insert the following message strings (this utility was introduced in Lab 2f): 


Label 

Message 

MSG_000 

ERROR: 

MSG_001 

Carry = 1 

MSG_002 

Borrow = 0 

MSG_003 

Overflow 

MSG_004 

Underflow 

MSG_005 

Too big 

MSG_006 

Too small 

MSG_007 

Divide by 0 

MSG_008 

Out of range 

MSG_009 

-32,768 

MSG_010 

Not implemented 
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With regard to message MSG_0 00, make sure you include a space 
following the colon (that is, the string should be “ERROR :”)■ As you will 
soon discover, we are going to create a disperr (“display error”) sub¬ 
routine that can be called from inside our math subroutines to report 
error conditions when they are detected. 

Adding a GETNUM subroutine 

Now, we are going to add three subroutines between the “Start” and 
“End Subroutine” comments. The first of these subroutines, called 
GETNUM (“get number”), allows you to enter a number by clicking four 
hexadecimal digits on the calculator’s keypad (you will indicate when 
you’ve finished by clicking the “Enter” key). This routine then uses these 
digits to form a 16-bit binary number that it places on the stack. 

The GETNUM subroutine is shown below in its entirety. This is 
followed by a detailed description as to the way in which this routine 
performs its magic. 

########## start of GETNUM subroutine 

########## Get four hex digits, use them to form a 16-bit binary 
########## value, and store that value on the stack 

########## Pop the return address off the stack and save it 
GETNUM: POPA # Pop the MS byte of return address 

STA [_GN_RADD] # off the stack and store it 

POPA # Pop the LS byte of return address 

STA [_GN_RADD+1] # off the stack and store it 

########## Load a series of key codes into 'INSTRING' until we see 
########## the 'Enter' key (we assume other keys are 0-9 and/or A-F 
########## and we don't perform any error checking) 

BLDX $0000 # Load the index register with 0 

_GN_LOOP: LDA [KEYPAD] # Load accumulator from keypad 

JN [_GN_LOOP] # Jump back if no key pressed 

CMPA $13 # Compare to code for 'Enter" key 

JZ [_GN_STR] # If the same, jump to process 

string 

STA [MAINDISP] # Copy this key code to main display 

STA [INSTRING,X] # Also Store this code in string 

INCX # Increment the index register 

JMP [_GN_LOOP] # Jump back and wait for another key 

########## Build a 16-bit binary number and push it in the stack 
_GN_STR: LDA [INSTRING+2] # Load accumulator with 3rd character 
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SHL 


# 

in 'INSTRING' and shift it left 


SHL 


# 

four bits ... 


SHL 


# 



SHL 


# 



OR 

[INSTRING+3] 

# 

OR result with 4th character and 


PUSHA 


# 

push this LS byte onto the stack 


LDA 

[INSTRING] 

# 

Load accumulator with 1st character 


SHL 


# 

in 'INSTRING' and shift it left 


SHL 


# 

four bits ... 


SHL 


# 



SHL 


# 



OR 

[INSTRING+1] 

# 

OR result with 2nd character and 


PUSHA 


# 

push this MS byte onto the stack 

########## 

Write i 

a space to the 

main display 

_GN_SPC: 

LDA 

$20 

# 

Load acc with ASCII code for space 


STA 

[MAINDISP] 

# 

Write it to the main display 

########## 

Return 

gracefully from 

this subroutine 

_GN_RET: 

LDA 

[_GN_RADD+1] 

# 

Get LS byte of return address from 


PUSHA 


# 

temp location and push onto stack 


LDA 

[_GN_RADD] 

# 

Get MS byte of return address from 


PUSHA 


# 

temp location and push onto stack 


RTS 


# 

Return from this subroutine 

_GN_RADD: 

.2BYTE 


# 

2-byte temp location used to store 




# 

the return address for this routine 

########## 

End of 

GETNUM subroutine 

#- 

— 



-# 


Before we begin, let’s take a moment to observe that all of the labels 
in this routine, with the exception of the name of the subroutine itself, 
start with the same four-characters (_GN_), where the “GN” is short for 
“GETNUM.” This helps to prevent the problems that can easily arise if 
we attempt to use identical labels in multiple subroutines. 

Also, observe the final real statement in this routine at the 
_GN_RADD label, where “RADD” is short for “Return Address.” This 
statement is used to reserve two bytes of data in which we are going to 
temporarily store the subroutine’s return address. (In some cases, we will 
make use of the global temporary data storage elements we reserved in the 
previous section. In other cases, it is preferable to use storage elements 
that are local to the subroutine in question, because this prevents any fu¬ 
ture nested subroutine calls from overwriting the same global locations.) 
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There is one last point to make before we plunge into the heart of 
this subroutine—observe the final comment line we used to terminate 
the subroutine: 



As you will come to see, when we have a large number of subroutines 
(each of which is, ideally, replete with comments, it can be a little tricky 
to spot where one stops and another begins. Using a special comment 
like this provides a nice visual indication as to the boundary between 
adjacent routines. 

Storing the return address 

Now, let’s consider the state of play just before we call the getnum sub¬ 
routine. The stack pointer (SP) wiU be pointing to whatever location in 
the memory is currently considered to represent the top of the stack 
(we’U reference this location as being at address $nnnn for the purpose 
of these discussions). Meanwhile, the two bytes in memory that are 
associated with the _GN_RADD label will contain unknown values 
Figure L4-l(a)]. 

As you will recall, when a JSR (“jump to subroutine”) instruction 
is used to call a subroutine like getnum, the return address (the address 
of the instruction immediately following the JSR) is automatically 
pushed onto the current top of the stack. As part of this process, the 



Memory 


Memory 


Memory 

GN RADD 

? 


? 


MS Return I 

GN RADD+1 

? 


? 


LS Return 1 







$nnnn-6 

? 


? 


? 

$nnnn-5 

? 


? 


? 

$nnnn-4 

? 


? 


? 

$nnnn-3 

? 


? 


? 

$nnnn-2 

? 


? 

SP 

? 

$nnnn-l 

? 


MS Return 


MS Return 

$nnnn 

? 

«-SP 

LS Return 


LS Return 








SP 


(a) Just before JSR 

to GETNUM 


(b) Just after JSR 

to GETNUM 


(c) Just after store 
return address 


Figure L4-1. The state of play when getnum is called. 














































CREATING THE TESTBENCH PROGRAM 


283 


stack pointer is modified to point to the next free location on the top of 
the stack [Figure L4-l(b)]. 

Sad to relate, we now have a bit of a problem, because the mission 
of the GETNUM routine is to build a 2-byte (16-bit) number and store it 
such that, when we finally exit getnum, this number appears on the top 
of the stack ready to be used by a subsequent routine. However, if we 
were to simply push a 2-byte number onto the top of the stack as it ap¬ 
pears in Figure L4-l(b), then when we eventually use a RTS (“return 
from subroutine”) to exit GETNUM, this instruction would mistakenly at¬ 
tempt to use our number as its return address with disastrous conse¬ 
quences. This why the first four instructions in GETNUM are used to pop 
the return address off the top of the stack and store it in our 2-byte tem¬ 
porary location at label _gn_radd, as shown in Figure L4-l(c) (the act 
of popping these two bytes off the stack returns the stack pointer to its 
original position). 

Reading and temporarily storing the key codes 

Now we want to read in a series of four hexadecimal digits. The way 
we’ve decided to implement this part of the subroutine is to loop 
around, reading the codes associated with buttons being pressed on the 
key pad and storing them as a string of characters until the user clicks on 
the “Enter” key. Purely for the purposes of this portion of our discus¬ 
sions, let’s assume that the user is going to click the following sequence 
of buttons: 


“3,” “A,” “6,” “C,” “Enter” 

Now, consider the global 10-byte temporary location called instring 
that we reserved earlier. Initially, this contains unknown values as shown 
in Figure L4-2(a). 

We commence by loading the index register (X) with 0, and then 
we start a loop at label _GN_loop. Initially, we perform an inner loop, 
loading the accumulator with values from the input port connected to 
the calculator’s keypad, waiting for a key to be pressed. 

When a key is pressed, we use a cmpa (“compare accumulator”) in¬ 
struction to compare the contents of the accumulator to $13, which is 
the code associated with the “Enter” key. If the value in the accumulator 
is equal to this code, the Z (zero) status flag will be set (loaded with a log¬ 
ic 1), in which case the JZ (“jump if zero”) instruction will cause us to 



284 


LABS FOR CHAPTER 4 INTEGER ARITHMETIC 












INSTRING 

? 

x=o 

$03 


$03 


$03 


$03 

INSTRING+I 

? 


? 

X=1 

$0A 


$0A 


$0A 

INSTRING+2 

? 


? 


? 

X=2 

$06 


$06 

INSTRING+3 

? 


? 


? 


? 

X=3 

$0C 

INSTRING+4 

? 


? 


? 


? 


? 

INSTRING+5 

? 


? 


? 


? 


? 

etc. 

? 


? 


? 


? 


? 












X=4 


(a) start (b) 1st digit (c) 2nd digit (d) 3rd digit (e) 4th digit 
Figure L4-2. Storing key codes as they are clicked. 


jump to label _GN_STR. Otherwise, we will copy the value in the accu¬ 
mulator to the output port driving the calculator’s main display, and also 
store into the next free location in our string. 

The STA [ INSTRING, X] instruction will store the value in the ac¬ 
cumulator into the memory location whose address is computed by 
adding the address associated with the instring label to the contents of 
the index register. The first time a key is pressed (the “3” key in our ex¬ 
ample), the index register contains 0, so the $03 code associated with this 
key is stored in memory location iNSTRiNG+0 [Figure L4-2(b)]. The 
index register is incremented to contain 1, and the program jumps back 
to _GN_LOOP to wait for the next key to be pressed. 

The second time a key is pressed (the “A” key in our example), the 
index register contains 1, so the $0A code associated with this key is 
stored in memory location lNSTRlNG+1 [Figure L4-2(c)]. And so it 
goes, until the user eventually clicks the “Enter” key, which causes the 
program to jump to label _GN_STR. 

Converting the key codes into a binary number 

Now, this wiU take a little bit of thought in order to understand exactly 
what we’re trying to do (actually doing it is easy-peasy). We currently 
have four bytes representing key codes stored in instring, and we 
want to take these key codes and convert them into a 2-byte (16-bit) 
binary number (we’ll refer to this number as NUM for the purpose 
of these discussions). We can represent this pictorially as shown in 
Figure L4-3. 

The only other trick to remember is that we wish to store the ensu¬ 
ing 2-byte number on the stack such that the most-significant (MS) byte 
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INSTRING INSTRING+I INSTRING+2 INSTRING+3 


Hexadecimal- 
Binary - 


0 

^ 1 

0 

0 

0 

0 

0 

0 

1 



0 

^ 1 

0 

^ 1 

0 

" 1 

0 

0 

0 

0 

1 

0 

iTo) 

0 

0 

0 

0 

0 

1 

1 


0 

0 

0 

0 

1 

1 

0 



Hexadecimal—► 3 A I 6 c 


Binary —► 0 


Oil 


0 101 0 1 


Oil 


0 0 


MS NUM LS NUM 

Figure L4-3. Converting the key codes into a binary number. 


is “on top” of the least-significant (LS) byte, which means we have to 
process the LS byte first. 

Bearing all of this in mind, consider what happens starting at the 
_GN_STR label. We start by loading the accumulator with the third key 
code (the one stored at instring+2), as shown in Figure L4-4(a). Then, 
we shift this code four bits to the left as shown in Figure L4-4(b), and OR 
it with the fourth key code (the one stored at instring+3 ), as shown in 
Figure L4-4(c). 

Now remember that after storing the return address in a safe place 
at the beginning of this subroutine, we left the stack pointer as shown in 


/ 

(a) Load ACC with 

INSTRING+2 

\ 

0 

6 1 <— Hexadecimal 

0 

0 

0 

0 

0 

1 

1 

o| •*— Binary 



(b) Shift ACC left [ 
four bits ^ 

6 

•*— Hexadecimal 

0 

1 

1 

0 

0 

0 

0 

o| <— Binary 


<> 

/ 

(c) OR ACC with 

INSTRING+3 

\ 

6 

<— Hexadecimal 

0 

1 

1 

0 

1 

1 

0 

o| •<— Binary 


\ -s / 


LS NOM 


Figure L4-4. Forming the LS byte of the binary number. 



























































































































































286 


LABS FOR CHAPTER 4 INTEGER ARITHMETIC 


GN RADD 

GN RADD+1 

Memory 

MS Return I 

LS Return 1 



$nnnn-6 

? 

$nnnn-5 

? 

$nnnn-4 

? 

$nnnn-3 

? 

$nnnn-2 

? 

$nnnn-l 

MS Return 

$nnnn 

LS Return 


Memory 



SP 


Memory 



SP 


(a) Just after store (b) Just after push (c) Just after push 
return address LS NUM MS NUM 


Figure L4-5. Pushing the 2-byte binary number onto the stack. 


Figures L4-l(c) and L4-5(a). Thus, after we’ve formed the LS byte of our 
2-byte number as shown in Figure L4-4(c), we push it onto the stack as 
shown in L4-5(b). (We don’t know about you, but even we are starting 
to get confused with all of these figure numbers!) ^ 

Now, we form the MS byte of NUM in the same way: we load the ac¬ 
cumulator with the first key code (at instring), shift this code four bits 
to the left, OR the result with the second key code (instring+1), and 
push the result onto the stack as shown in Figure L4-5(c). 

Retrieving the return address 

Now we’re really racing toward the end of this subroutine. When we get 
to the _GN_SPC label, we write a space character to the main display (as 
you will see, this will make things look “pretty” when we come to use this 
testbench program). Next, at the _GN_RET label, we retrieve the LS byte 
of the return address from its temporary location and push it onto the 
stack [Figure L4-6(b)]. Similarly, we retrieve the MS byte of the return 
address and push it onto the stack [Figure L4-6(c)]. 

Finally, we execute the RTS (“return from subroutine”) instruction, 
which automatically pops the return address from the top of the stack, as 
shown in Figure L4-6(d), and returns us to wherever the GETNUM sub¬ 
routine was called from. The point is that the stack now contains our 

^But look on the bright side; at least you don’t have to draw the figures! 
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Memory 


Memory 

GN RADD 

MS Return 


MS Return I 

GN RADD+1 

LS Return 


LS return | 





$nnnn-6 

? 


? 

$nnnn-5 

? 


? 

$nnnn-4 

? 


? 

$nnnn-3 

? 


? 

$nnnn-2 

? 

-^SP 

LS Return 

$nnnn-1 

MS NUM 


MS NUM 

$nnnn 

LS NUM 


LS NUM 






Memory 



SP 


MS Return 


LS Return 


MS NUM 


LS NUM 


Memory 


SP 



SP 


(a) Just after push (b) Just after push 
MS NUM LS Return 


(c) Just after push 
MS Return 


(d) Just after 
execute rts 


Figure L4-6. Pushing the return address onto the stack. 


2-byte number, which is waiting to be used by one of our math sub¬ 
routines, as we will see in future labs. 

Note that when we retrieve the LS and MS bytes of the return ad¬ 
dress in Figures L4-6(b) and L4-6(c), we leave their values showing (but 
grayed-out) in the _GN_RADD+1 and _GN_RADD locations, respectively. 
This is because the act of copying these values into the accumulator 
doesn’t destroy the original versions stored in our temporary memory 
locations. (Truth to tell, popping the return address out of the two loca¬ 
tions on the top of the stack doesn’t corrupt these values either, but ac¬ 
cessing them would be a bit tricky, so we’ve shown these locations with 
their values lined through.) 

Once you are confident that you understand how this subroutine 
works, enter it between the “Start” and “End Subroutine” comments and 
then use the assembler’s File > Save command to save your work. 

Improving on our subroutine 

It wouldn’t surprise us if you’ve noticed that, in many respects, our 
GETNUM routine leaves something to be desired. It performs no error¬ 
checking, it doesn’t warn us if the user enters an incorrect number of 
characters, and it doesn’t even chastise the user if he or she presses a 
nonhexadecimal key. For example, what would happen if the user were 
to enter the sequence “3,” “A,” “C,” “Enter”? Alternatively, what 

would happen if the user clicked only three keys before pressing the 
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“Enter” button? What if they clicked five? Even worse, what if they 
clicked eleven or more, which would exceed the 10-byte capacity of IN- 
STRING and start overwriting subsequent memory locations? 

The point is that creating “bullet-proof” input routines takes a lot 
of thought and effort, and we decided not to spend too much time on 
this aspect of things in the case of this simple testbench program. But 
once you’ve got everything working, you might decide to revisit this rou¬ 
tine and augment it with some additional tests and warnings of your own 
or replace it in its entirety with something better. Generally speaking, it is 
immaterial how this routine performs its machinations as long as it 
leaves a 2-byte binary number on the top of the stack when it is done. 

Adding a DISPNUM subroutine 

For the moment, let’s assume that we have performed some math func¬ 
tion such as adding two 2-byte binary numbers together, and we’ve left 
the 2-byte result on the top of the stack. The purpose of the dispnum 
subroutine is to retrieve this 2-byte result from the stack and convert it 
into a sequence of character codes that are presented to the calculator’s 
main display. 

The DISPNUM subroutine is shown below in its entirety. This is fol¬ 
lowed by a detailed description as to the way in which this routine works. 

########## Start of DISPNUM subroutine 

########## Retrieve a 16-bit binary value from the stack, convert 
########## it into 4 hex digits, and display these digits 

########## Pop the return address off the stack and save it 
DISPNUM: POPA # Pop the MS byte of return address 

STA [_DN_RADD] # off the stack and store it 

POPA # Pop the LS byte of return address 

STA [_DN_RADD+1] # off the stack and store it 

########## Write an equals sign ('=') and space to the main display 
_DN_EQ: LDA $3D # Load acc with ASCII code for 

STA [MAINDISP] # and store it to the main display 

LDA $20 # Load acc with ASCII code for ' ' 

STA [MAINDISP] # and store it to the main display 

########## Break-out and display the MS byte {1st and 2nd digits) 
_DN_MSB: POPA # Pop the MS byte off the stack 

PUSHA # and push a copy back for later 

# Then shift it right by 4 bits 

# : 


SHR 

SHR 
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SHR 

# : 


SHR 

# : 


AND 

$0F # Clear MS 4 bits to 0 


STA 

[MAINDISP] # and store 1st digit to main display 


POPA 

# Pop the MS byte off the stack again 


AND 

$0F # Clear MS 4 bits to 0 


STA 

[MAINDISP] # and store 2nd digit to main display 

########## 

Break-out and display the LS byte (3rd and 4th digits) 

_DN_LSB: 

POPA 

# Pop the LS byte off the stack 


PUSHA 

# and push a copy back for later 


SHR 

# Then shift it right by 4 bits 


SHR 

# : 


SHR 

# : 


SHR 

# : 


AND 

$0F # Clear MS 4 bits to 0 


STA 

[MAINDISP] # and store 3rd digit to main display 


POPA 

# Pop the LS byte off the stack again 


AND 

$0F # Clear MS 4 bits to 0 


STA 

[MAINDISP] # and store 4th digit to main display 

########## 

Return 

gracefully from this subroutine 

_DN_RET: 

LDA 

[_DN_RADD+1] # Get LS byte of return address from 


PUSHA 

# temp location and push onto stack 


LDA 

[_DN_RADD] # Get MS byte of return address from 


PUSHA 

# temp location and push onto stack 


RTS 

# Return from this subroutine 

_DN_RADD: 

2 BYTE 

# 2-byte temp location used to store 

# the return address for this routine 

########## 

End of 

DISPNUM subroutine 

#- 

— 

-# 


In this case, all of the labels inside this routine begin with the char¬ 
acter sequence _dn_ (for “display number”), and the 2-byte temporary 
location reserved at the end of the routine that is used to store the return 
address is called _dn_radd. 

For the purposes of these discussions, let’s assume the 2-byte num¬ 
ber on the top of the stack that we wish to display has the hexadecimal 
value $9C7E, and that we’ll refer to this value as RES (for “result”). Now, 
let’s consider the state of play just before we call the dispnum subrou¬ 
tine. The stack pointer (SP) will be pointing to whatever location in the 
memory is currently considered to represent the top of the stack. Mean¬ 
while, the two bytes in memory that are associated with the _dn_radd 
label will contain unknown values [Figure L4-7(a)]. 
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(a) Just before JSR 
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(b) Just after JSR 

to DISPNUM 


(c) Just after store 
return address 


Figure L4-7. The state of play when DISPNUM is called. 


Once again, when a JSR (“jump to subroutine”) instruction 
is used to call dispnum, the return address is automatically pushed 
onto the current top of the stack and the stack pointer is modified 
to point to the next free location on the new top of the stack [Figure 
L4-7(b)]. As usual, the first four instructions in DISPNUM are used to 
pop the return address off the top of the stack and store them in 
our 2-byte temporary location at label _DN_RADD, as shown in 
Figure L4-7(c). 

While we’re here, let’s quickly note that the next four instructions, 
starting at label _DN_EQ, are used to write an equals sign (“=”) and a 
space character (“ ”) to the main display so as to make the output look 
more aesthetically pleasing. 

Now, let’s consider just what it is that we need to do in order to 
display the 2-byte number on the top of the stack (Figure 4-8), and then 
we’ll discuss how to do it. 

As we see, we wish to extract four 4-bit nybbles from our 2-byte re¬ 
sult, and then convert each nybble into an 8-bit character code to be 
copied to the main display. We start at _DN_MSB by processing the most- 
significant byte of the result. First we pop the MS RES byte off the stack 
into the accumulator as shown in Figure L4-9(a) (note that, in the next 
line of the program, we push a copy of MS RES back onto the stack be¬ 
cause we’ll need it again in a moment). 
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Figure L4-8. Converting the binary number into character codes. 


Next, we shift the contents of the accumulator four bits to the 
right. However, due to the fact that our virtual computer’s SHR 
(“shift right”) instruction performs an arithmetic shift, the most- 
significant bit (a “1” in this case) keeps on getting copied back into 
itself, resulting in the accumulator containing a value of $F9 [Figure 
L4-9(b)]. Thus, we next AND the contents of the accumulator with 
a value of $0F so as to clear the most-significant four bits to 0 
[Figure L4-9(c)], and then we write the resulting character code to the 
main display. 


(a) Load ACC with 
MS RES 


(b) Shift ACC right 
four bits 


(c) AND ACC 
with $0F 
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(d) Load ACC with 
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Character 2 


Figure L4-9. Forming the character codes corresponding to MS RES. 
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Now, we pop the MS RES byte off the stack into the accumulator a 
second time [Figure L4-9(d)]. In this case, all we have to do is AND the 
contents of the accumulator with a value of $0F so as to clear the most- 
significant four bits to 0 [Figure F4-9(e)], and then we write this charac¬ 
ter code to the main display. 

We then process the least-significant byte of the result in a similar 
manner at label _dn_lsb. Finally, we reach the _dn_ret label, which is 
where we retrieve the return address from its temporary location, push it 
onto the stack, and use a RTS (“return from subroutine”) instruction, 
which returns the program to whichever point the DISPNUM routine was 
called from. 

Now, enter this routine somewhere between the “Start” and “End 
Subroutine” comments (preferably, just after the getnum routine) and, 
as usual, use the assembler’s File > Save command to save your work. 


Adding a DISPERR subroutine 

Fast, but not least, we wish to create a disperr (“display error”) sub¬ 
routine that we can use to warn us if our program detects that something 
has gone wrong. Cast your mind back to the Reserving global temporary 
data locations and messages section earlier in this lab, in which we stored 
the following messages: 


Label 


Message 


MSG_0 0 0 
MSG_0 01 
MSG_002 
MSG_003 
MSG_004 
MSG_0 0 5 
MSG_006 
MSG_007 
MSG_0 0 8 
MSG_0 0 9 
MSG_010 


ERROR: 

Carry = 1 
Borrow = 0 
Overflow 
Underflow 
Too big 
Too small 
Divide by 0 
Out of range 
-32,768 

Not implemented 


Now, let’s assume that our program detects that it has generated a 
value that is too large. In such an event, the message associated with label 
MSG_005 would be reasonably appropriate. In this case, the program 
could call our DISPERR routine as follows: 
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BLDX MSG_005 # Load X reg with start of msg 005 

JSR [DISPERR] # Call the error message routine 

That is, we use a bldx (“big load index register”) instruction to load the 
index register (X) with the address of the first character in the desired er¬ 
ror message, then we call the disperr subroutine. Now let’s look at the 
DISPERR routine itself: 

########## start of DISPERR subroutine 

########## Display an error message and then quit the program 
########## First clear the display 

DISPERR: LDA CLRCODE # Load ACC with clear code 

STA [MAINDISP] # and copy it to the main display 

########## Display the word "Error: " (note the space) 

_DE_ERR: BSTX [TMP2BYTE] # Store the value in the X register 

BLDX MSG_000 # Load X reg with start of msg 000 

_DE_LUPA: LDA [0,X] # Load a character from the msg 

JZ [_DE_MSG] # If it's a NUL jump to next bit 

STA [MAINDISP] # Otherwise copy it to main display 

INCX # Increment the index register 

JMP [_DE_LUPA] # Jump back for next character 

########## Now display the main error message then terminate 
_DE_MSG: BLDX [TMP2BYTE] # Reload the X reg's original value 

_DE_LUPB: LDA [0,X] # Load a character from the msg 

JZ [$0000] # If it's a NUL terminate the program 

STA [MAINDISP] # Otherwise copy it to main display 

INCX # Increment the index register 

JMP [_DE_LUPB] # Jump back for next character 

########## End of DISPERR subroutine 


########## This is where the math subroutine will go 

Observe that we are not concerned with storing the return address 
in this case, because once the disperr routine has finished displaying 
the required message, it will terminate the program. 

First, we clear the calculator’s main display by loading the accumu¬ 
lator with the display’s clear code and copying it to the display. Now, we 
are at label _DE_ERR, at which point we copy the current value in the 
index register—the address of the first character in the message we wish 
to display—into our temporary global location at label TMP2BYTE. 
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We then load the index register with the address of the first charac¬ 
ter in the message associated with label MSG_0 0 0 (this message is 
“ERROR: ”)• Now we enter a loop at label _de_lupa that retrieves the 
character pointed to by the index register and checks to see if it’s a NUL 
character. If it is a NUL, we jump to label _de_msg; otherwise, we copy 
the character to the main display, increment the index register, and jump 
back to the beginning of the loop. Thus, this loop will cause the main 
display to show the following string: 

ERROR: 

Once this portion of the task is completed and the program reaches 
label _DE_MSG, it reloads the index register with the start address of 
the original message. Next, we enter a loop at label _de_lupb that re¬ 
trieves the character pointed to by the index register and checks to see 
if it’s a NUL character. If it is a NUL, we jump to address $0000 and ter¬ 
minate the program; otherwise, we copy the character to the main dis¬ 
play, increment the index register, and jump back to the beginning of 
the loop. 

Thus, in this particular example, the main display will end up 
showing the following string of characters: 

ERROR: Too big 

You know the drill: enter this routine after the dispnum routine and use 
the assembler’s File > Save command to save your work. 

Creating the body of the program 

Good grief! As you’ll see, building this testbench program has actually 
taken much more effort than creating the math subroutines themselves, 
but we’re almost finished. All we have to do is to enter the main body of 
the program as follows: 

########## Get two 16-bit numbers and push them onto the top of the 
########## stack; perform some action on them and display the result 
MAINLOOP: JSR [GETNUM] # Get 1st 16-bit number (NOMA) 

JSR [GETNUM] # Get 2nd 16-bit number (NUMB) 

### THIS IS WHERE WE WILL CALL THE MATH ROUTINE 

JSR [DISPNUM] # Display 16-bit number from stack 

########## Wait for any key to be pressed, then clear the main 
########## display and do it all again 
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WAITKEY: 

LDA 

[KEYPAD] 

# 

Load 

accumulator 

from keypad 


JN 

[WAITKEY] 

# 

Jump 

back if no key pressed 


LDA 

CLRCODE 

# 

Load 

accumulator 

with clear code 


STA 

[MAINDISP] 

# 

and store it to 

the main display 


JMP 

[MAINLOOP] 

# 

Jump 

back and do 

it all again 


We’ll commence by considering the statements associated with the 
MAINLOOP label. First we call our getnum subroutine, which, as we 
know, allows us to key in four hexadecimal codes that are converted into 
a two-byte number that will be pushed onto the stack. Assuming that the 
user clicks the following sequence of buttons, 

“3,” “A,” “6,” “C,” “Enter” 

then the state of the stack immediately after we return from this first call 
to the GETNUM routine will be as shown in Figure L4-10(a). 

Now, we call getnum for a second time. Assuming that the user 
clicks the following sequence of buttons, 

CCy-' » J> CC 1 J> CC^ » CCt' j _ j> 

6, 2, 1, 2, Enter 

then the state of the stack immediately after we return from this second 
call to the GETNUM routine will be as shown in Figure L4-10(b). 

At this point, we haven’t actually created any of our math subrou¬ 
tines. However, purely for the sake of discussion, let’s assume that we 
now call a subroutine called _add^ that retrieves our two 2-byte numbers 
from the top of the stack, adds them together, and pushes the 2-byte re¬ 
sult back onto the stack as shown in Figure L4-10(c) ($3A6C + $6212 = 
$9C7E). 

Next, we call our dispnum routine, which retrieves a 2-byte num¬ 
ber from the top of the stack, converts it into corresponding display 
codes, and presents these codes to the calculator’s main display. In the 
case of our testbench program, this routine does not leave a copy of the 
value to be displayed on the stack (this will change when we come to cre¬ 
ate a real calculator program). Thus, the state of the stack following the 
DISPNUM routine is as shown in Figure L4-10(d). 

Finally, when we reach the WAITKEY label, the program waits for 
any key on the calculator’s front panel to be clicked, then it clears the 

^Note that we have to call our subroutine something like _add (with a leading 
underscore character) because we already have an instruction called add (without 
the underscore). 
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Memory 


Memory 


Memory 


Memory 

$nnnn-6 

? 


? 


? 


? 

$nnnn-5 

? 


Old "Stuff’ 


Old “Stuff” 


Old “Stuff’ 

$nnnn-4 

? 


Old “Stuff' 

SP 

Old "Stuff 


Old "Stuff’ 

$nnnn-3 

Old "Stuff’ 


$62 


Old "Stuff 


Old "Stuff' 

$nnnn-2 

Old “Stuff’ 

-.-SP 

$12 


Old "Stuff 

SP 

Old "Stuff’ 

$nnnn-l 

$3A 


$3A 


$90 


Old "Stuff’ 

$nnnn 

$60 


$60 


$7E 


Old “Stuff’ 










SP 


(a) Just after 1 st 

GETNUM 


(b) Just after 2ncl 

GETNUM 


(c) After ADD routine 
(to be created) 


(d) Just after 

DISPNUM 


Figure L4-10. The state of the stack at key points in the program. 


main display and jumps back to MAINLOOP to do the whole thing all 
over again. 

We’re nearly there. Enter these lines of code between the “Start” 
and “End of main program body” comments and, you guessed it, use the 
assembler’s File > Save command to save your work. 

Testing the Testbench Program 

Ensure that the calculator is powered-up. Assemble (and debug) your 
new program. Click the Reset button on the front panel to ensure that 
the calculator is halted. Use the Memory > Purge RAM command to 
scramble its memory, then use the Memory > Load RAM command to 
load the new skeleton-lab4.ram file. 

Now click the Run button to execute the program and observe the 
main display being cleared. The program is waiting for you to input your 
first number, so click on the sequence of keys we discussed earlier: 

3, A, 6, C, Enter 

Remember that, in addition to building a 2-byte number and placing it 
on the stack, the getnum routine also copies the digits back to the main 
display, and then it writes out a space character for good measure, so the 
main display will now show 


3A6C 

Next, click on the second sequence of keys we discussed earlier as follows: 

CC/^ ct-« cc 1 yj yy u-r-' j. 

6, 2, 1, 2, hnter 
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Once again, the GETNUM routine will copy these back to the main display 
and follow them with a space character, so for a fraction of a second the 
main display will show 

3A6C 6212 

If we had actually created a math subroutine called something like 
_ADD, this is the point where it would be called from the main program; 
but we have not yet created that subroutine so, instead, we immediately 
call our DISPNUM routine, which commences by outputting an equals- 
space (“= ”) pair of characters followed by whatever 2-byte number it 
finds on top of the stack. As that 2-byte number is currently the last 
number we entered, the main display will now show 

3A6C 6212 = 6212 

The program is now waiting for you to click another key. When 
you do so, it clears the display and then jumps back to the beginning to 
await your entering of two more numbers. 

Experiment by using a few different number sequences. What hap¬ 
pens if on the second number you enter only three digits before clicking 
the “Enter” key? What happens if you enter 5? 


Ba What will happen if you click the “0” key four times for 
your first number followed by one or more nonhexadecimal keys when 
forming your second number? Eor example. 


“0,” “0,” “0,” “0,” “Enter” {Eirst number} 

“+” “*,” “/,” “Enter” {Second number} 


Try this for yourself, note the result, and try to explain what you see 
to your own satisfaction before perusing and pondering the answer on the 
following page. 
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66ZZ = #### 0000 


Avoqs 

Mou [JIM XBjdsip urem aqi os ‘uioij auioo ssnpA asaqj ajoqM aioa j^usaop aup 
-noi PMflNdSia 3H1 asjnoD jq aqj uo 66ZZ$ Jo anpA aUq-Z b Supo^d pmN 
-xao HI qnsai qiM puo „‘+„ jo aouanbas b ut §up[aqD ‘snqj^ 

■(IIIO TTIO^Buiq) SuTureiuoa jO}B|nuinDaB 
aq;SuiABay/qaiaqi ‘Zaq aqj qiiAvpaiBOOssB (niO TOOO^^Hiq) apoa aqj 
qiTM pa’-ao sq uaqj qiAv siqx ‘(0000 OTIO^raiq) 09$ Smurejuoa joiB|nuinDaB 
aqi §upBa{ ‘qay aqi oj sqq inoj payiqs puB ioiB|nuinaaB aqi ojui papBO{ aq qiAv 
Xaq aqi qjpw pajBpossB (QUO TOOO ^Buiq) apoa 9x$ aqi ‘jaqiunu ZjBuiq mo 
JO ax(q sjAj aqi mioj oi pasn si siapBJBqa jo aiBd isjij aqi uaqAv ‘XpBjTmis 

■(TOOT TOOT ^TOiq) 66$ 

SuTUTBiuoa joiBjnmnaaB aqi SuiABajZqaaaqi ‘Xaq aqi qiiAv paiopossB (tOOT 
TOOO ^Buiq) apoa 6T$ api qJiAi pa-TIO aq ^aqi qiM siqx '(0000 OOOT ^muiq) 
08$ SuiuTBiuoa joiBxnumaaB aqi SuiABax ‘ijaj aqi oi sqq anoj paqiqs puB aoiBxnui 
-naaB aqi oiui papBOj aq xpM Zaq aqi qipw pappossB (oOOT TOOO ^-iBuiq) apoa 
8T$ aqx '.laqumu /muiq mo jo aiZq gq aqi uuoj oi saapBiBqa jo ared puoaas 
aqi sasn auiinoj wnNXao aqi uaqAv uaddBq jqAv pqAv lapisuoa spaj Avojq 

•(lapBTBqa PTIbaut ub qijM paiuasaad spi ji aapBTBqa punod b Moqs 
qiM q iBqi qans ZBjdsip uibui aqi pauSisap aM ‘aaAaAvoq ‘aaipBjd ui) uaddoq 
qiM iBqM Avouq quop aM Xjoaqi ui ‘pauqapun am sapoa asaqi sy '^Bidsip 
UIBUI aqi Zq papoddns ZqBupB lou am 6T$ P™ ‘8T$ ‘ZT$ ‘9T$ sapoa pqi 
aas qiM noZ ‘oz qBq ui j j-jq amSiq ib qooj noZji ‘laAaMOfj "ZB^dsip ureiu aqi 
01 qaoq q saidoa ZpiBipamuii puB uoiinq pqi qqM paiBpossB apoa aqi spBaa 
auquoi wnNxao aqi ‘paqaqa si uonnq qaBa sy 'ZpAipadsaj ‘6T$ piiB ‘8T$ ‘ZT$ 
‘9j$ aJB sZaq puB aqi qqM pappossB sapoa aqq j3A/\SU\f ^ 
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Creating a 16-bit 
ADD Subroutine 


Objective: To create a general-purpose subroutine that can add two 

2-byte (16-bit) unsigned binary numbers together. 
Duration: Approximately 45 minutes. 

Before We Start 

In Lab 4a, we created a testbench program that we are going to use to 
verify the functionality of our math routines. For the purposes of these 
discussions, the interesting portion of this testbench program was the 
first part of its main body, as follows: 

MAINLOOP: JSR [GETNUM] # Get 1st 16-bit number (NUMA) 

JSR [GETNUM] # Get 2nd 16-bit number (NUMB) 

### THIS IS WHERE WE WILL CALL THE MATH ROUTINE 

JSR [DISPNUM] # Display 16-bit number from stack 

The purpose of this lab is to create a subroutine called _add^ that will 
add two 2-byte (16-bit) unsigned binary numbers together (this routine 
will be modified to deal with signed binary numbers in Lab 4e). We 
will investigate the creation of the _add routine shortly, but for the 
moment, let’s simply assume that we will eventually modify the test- 
bench routine to call this routine as follows (the change is highlighted 
in gray): 


MAINLOOP: 

JSR 

[GETNUM] 

# 

Get 1st 

16-bit number (NUMA) 


JSR 

[GETNUM] 

# 

Get 2nd 

16-bit number (NUMB) 


JSR 

[_ADD] 

# 

Add NUMA and NUMB together 


JSR 

[DISPNUM] 

# 

Display 

16-bit number from stack 


'The reason for calling this subroutine _add is that we can’t use add without the 
underscore because we already have an instruction with that name. 
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We commence by calling our getnum routine twice so as to obtain two 
2-byte numbers on the top of the stack. We shall refer to these numbers 
as NUMA and numb. This means that the state of the stack when we return 
from the second call to GETNUM will appear as shown in Figure L4-ll(a). 

The task in store for our _ADD routine is to retrieve these two 2- 
byte numbers from the stack, add them together, and store the 2-byte re¬ 
sult (which we’ll refer to as res) back on the stack as shown in Figure 
L4-ll(b). Finally, we call the DISPNUM routine, which retrieves this re¬ 
sult from the stack and presents it to the main display as four hexadeci¬ 
mal characters [Figure L4-ll(c)]. 

Just to remind ourselves, the number to which another number is 
to be added is called the augend, a number that is added to another num¬ 
ber is called the addend, and the result from adding two or more num¬ 
bers together is called the sum. For example, if we were to enter $3A6C 
and $6232 as the two numbers to be added, we can represent the addi¬ 
tion operation as follows: 


Augend 

-t 

Addend = 

Sum 

(Official terminology) 

$3A6C 

+ 

$6232 = 

$9C9E 

(Example values) 

NUMA 

+ 

NUMB = 

RES 

(Names used in these discussions) 


The 16-bit _ADD Subroutine Itself 

The _ADD subroutine is shown below in its entirety. This is followed by a 
detailed description as to the way in which this routine functions. 


Memory Memory Memory 


$nnnn-6 

? 


? 


? 

$nnnn-5 

? 


? 


? 

$nnnn-4 

? 

.^SP 

? 


? 

$nnnn-3 

MS NUMB 


Old “Stuff 


Old "Stuff 

$nnnn-2 

LS NUMB 


Old "Stuff 

SP 

Old "Stuff 

$nnnn-l 

MS NUMA 


MS RES 


Old "Stuff 

$nnnn 

LS NUMA 


LS RES 


Old “Stuff 






^ — 


(a) Just after 2nd (b) After _add routine 
GETNUM (to be created) 


(e) Just after 

DISPNUM 


Figure L4-11. The state of the stack at key points in the program. 
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Observe the big block of comments at the top of the routine. It isn’t 
really necessary for you to replicate all of these comments, but it would 
be good practice to do so. The reason for providing this level of informa¬ 
tion is to ease the task of other programmers who may wish to incorpo¬ 
rate your routine into their code (and also to aid your own memory 
when you come to revisit this routine in the future). 


####################################################################### 


# Name: _ADD 

# 

# Function: Add two 16-bit UNSIGNED binary numbers together and 
return a 16-bit result in the range 0 through 65,535 


# 

# 

# Entry: 

# 

# 

# 

# 

# 

# 

# 

# Exit: 

# 

# 

# 

# Modifies: 

# 

# Size: 

# 


Top of stack 

Most-significant byte of return address 
Least-significant byte of return address 
Most-significant byte of second number (addend) 
Least-significant byte of second number (addend) 
Most-significant byte of first number (augend) 
Least-significant byte of first number (augend) 

Top of stack 

Most-significant byte of result (sum) 

Least-significant byte of result (sum) 

Accumulator (also index register if error) 

Program = 50 bytes 
Data = 5 bytes 


####################################################################### 


########## Get return address from stack and store it 
_ADD: POPA # Retrieve MS byte of return 

STA [_AD_RADD] # address from stack and store it 

POPA # Retrieve LS byte of return 

STA [_AD_RADD+1] # address from stack and store it 


########## Get addend and augend from stack 


_AD_GNUM: POPA 


# 

Retrieve MS 

byte of addend 

from 

STA 

[_AD_NUMB] 

# 

stack and 

store it 


POPA 


# 

Retrieve LS 

byte of addend 

from 

STA 

[_AD_NUMB+1] 

# 

stack and 

store it 


POPA 


# 

Retrieve MS 

byte of augend 

from 

STA 

[_AD_NUMA] 

# 

stack and 

store it 


POPA 


# 

Retrieve LS 

byte of augend 

from 



# 

stack Sc leave it in the ACC 
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########## 

Perform 

the addition 



_AD_DOIT: 

ADD 

[_AD_NUMB+1] 

# 

Add LS byte of addend to ACC 


PUSHA 


# 

and push LS sum onto stack 


LDA 

[_AD_NUMA] 

# 

Load ACC with MS byte of augend 




# 

from temp location 


ADDC 

[_AD_NUMB] 

# 

Add MS byte of addend to ACC w 


PUSHA 


# 

carry and push MS sum onto stack 

########## 

Make sure there isn't a carry out from the MS addition 

_AD_CHK; 

JNC 

[_AD_RET] 

# 

If carry flag = 0 jump to return 


BLDX 

MSG_001 

# 

Load X reg with addr of message 


JSR 

[DISPERR] 

# 

Jump to display error subroutine 




# 

(which terminates the program) 

########## 

Return ■ 

to main program 


_AD_RET: 

LDA 

[_AD_RADD+1] 

# 

Load ACC with LS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


LDA 

[_AD_RADD] 

# 

Load ACC with MS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


RTS 


# 

That's it, exit the subroutine 

########## 

Reserve 

temp locations 

for this subroutine 

_AD_RADD: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the return address 

_AD_NUMA: 

.BYTE 


# 

Reserve 1-byte temp location for 




# 

the MS byte of the augend 

_AD_NUMB: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the addend 

########## 

This is 

the end of the 

_ADD subroutine 

#- 

— 


- 

-# 


In this case, all of the labels inside this routine begin with the char¬ 
acter sequence _ad_ (for “add”)- Observe the 2-byte temporary location 
at the end of the routine called _ad_radd, that is used to store the return 
address. Also, observe the 1-byte temporary location, called _ad_numa, 
that will be used to store the most-significant (MS) byte of the augend, 
and the 2-byte temporary location, called _ad_numb, that is used to store 
both the most-significant and least-significant (LS) bytes of the addend. 

Storing the return address 

As we previously discussed, our testbench program is going to arrange for 
two 2-byte numbers to be stored on the top of the stack [Figure L4-12(a)]. 
As usual, when we first call the _add subroutine, its return address will be 
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Memory Memory Memory 


AD RADD 

? 


? 


MS Return I 

AD RADD+1 

? 


? 


LS Return | 













$nnnn-6 

? 


? 

SP 

? 

$nnnn-5 

Old "Stuff’ 


MS Return 


MS Return 

$nnnn-4 

Old “Stuff” 

^SP 

LS Return 


LS Return 

$nnnn-3 

MS NUMB 


MS NUMB 


MS NUMB 

$nnnn-2 

LS NUMB 


LS NUMB 


LS NUMB 

$nnnn-l 

MS NUMA 


MS NUMA 


MS NUMA 

$nnnn 

LS NUMA 


LS NUMA 


LS NUMA 








(a) Just before JSR (b) Just after JSR (c) Just after store 
to ADD to ADD return address 


Figure L4-12. The state of play when _add is called. 


automatically placed on the top of the stack [ Figure L4-12 (b) ]. Thus, the 
first thing we do at label _ADD is to retrieve the return address and squirrel 
it away in our temporary _AD_RADD location [Figure L4-12(c)]. 

Retrieving the numbers to be added from the stack 

Now, consider the sequence of instructions starting at the _AD_GNUM 
label (where “GNUM” is short for “get numbers”) as illustrated in 
Figure L4-13. 

We start by popping the MS byte of numb off the top of the stack 
and copying it into the memory location associated with label _AD_NUMB 
[Figure L4-13(a)]. Next, we pop the least-significant (LS) byte of numb 
off the top of the stack and copy it into the memory location at 
_AD_NUMB+1 [Figure L4-13(b)]. 

Now, we pop the MS byte of numa off the top of the stack and copy 
it into the memory location associated with label _AD_NUMA [Figure 
L4-13(c)]. Finally, we pop the LS byte of numa off the top of the stack 
and leave this value in the accumulator [Figure L4-13(d)]. 

Actually performing the addition 

As we’ve popped both of our 2-byte numbers off the stack, the stack is 
now empty, as shown in Figure L4-14(a). 

The task of actually performing the addition, which commences at 
label _AD_DOiT, is surprisingly easy. We already have the LS byte of 
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AD NUMB AD NUMB + 1 



AD NUMB AD NUMB+1 


/ ^ \ / ^ \ 


MS NUMB 1 

LS NUMB 1 


_1 

_1 


\ ^ _ / \ ^ _ / 


_AD_NUMA Accumulator 

(a) Pop MS NUMB off the stack 


_AD_NUMA Accumulator 

(b) Pop LS NUMB off the stack 


AD 

NUMB 

AD NUMB+l 

AD 

NUMB 

AD NUMB+1 

/ 

^ \ 

/ ^ \ 

/ 

\ 

/ ■" \ 

MS 

NUMB 1 

LS NUMB 1 

MS 

NUMB 1 

LS NUMB 1 


MS 

NUMA 1 

1 

MS 

NUMA 1 

LS NUMA 1 

\ 



\ 

/ 


AD 

NUMA 

Accumulator 

AD 

NUMA 

Accumulator 


(c) Pop MS NUMA off the stack (d) Pop LS NUMA off the stack 

Figure L4-13. Retrieving the numbers to be added from the stack. 


NUMA (the augend) in the accumulator, so we use an add [numb+1 ] (a 
standard add instruction) to add the LS byte of NUMB (the addend) to the 
contents of accumulator, and then we push the result onto the stack, as 
shown in Figure L4-14(b). 

This addition will, of course, load the C (carry) flag with a 0 or 1 
depending on the values being added. Next, we use a lda [numa] in¬ 
struction load the MS byte of numa into the accumulator. Then we use 
an ADDC [NUMB] (“add with carry”) instruction to add both the MS 
byte of NUMB and the current contents of the carry flag to the accumu¬ 
lator, and then we push the result onto the stack as shown in Figure 
L4-14(c). 

Testing for errors 

Before we consider the portion of the _add subroutine starting at label 
_AD_CHK, we need to remember that the main testbench program dis¬ 
cussed in Lab 4a was equipped with a series of error message strings asso¬ 
ciated with labels MSG_000, MSG_001, MSG_002, and so on. Further¬ 
more, the testbench program includes a DISPERR (“display error”) 
subroutine. 
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(a) Just before the 
addition itself 


(b) After push 
LS result 


(c) After push 
MS result 


Figure L4-14. The state of the stack as we perform the addition. 


For the purposes of this lab, we’re assuming that we’re working 
withl6-bit unsigned binary numbers. This means that the range of num¬ 
bers we can support is $0000 through $FFFF (or 0 through 65,535 in dec¬ 
imal). If the final result from our addition is larger than this, the carry 
flag will contain a logic 1, thereby indicating an error condition. 

Thus, we perform a test on the carry flag at label _AD_CHK. If the 
carry flag contains a 0, which tells us that everything is OK, the JNC 
(“jump if not carry”) instruction will cause the program to jump to label 
_AD_RET. Otherwise, we load the index register with the value associated 
with label MSG_001 and then use a JSR (“jump to subroutine”) to jump 
to our DISPERR routine. 


Ideally, our general-purpose math subroutines are going to be created in such a way as to facUitate 
translating them into another assembly language for use on a real microprocessor or microcontroller. 

Thus, with the exception of this error check, the rest of the _add subroutine is totally self-contained—it uses 
its own local temporary storage locations and its only interaction with the outside world is via the stack. 

If we did wish to port this routine to another language, we would have several options, as follows: (a) cut this 
error test out (not recommended), (b) keep the test but embed the message string and associated display code 
inside this routine, or (c) replicate the external environment in the form of the message strings and DISPNUM 
subroutine. 


Retrieving the return address 

Assuming that our error test didn’t detect any problems, we arrive at the 
_AD_RET label with the result from the addition on the top of the stack 
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[Figure L4-15(a)]. We retrieve the LS byte of the return address from its 
temporary location and push it onto the stack [Figure L4-15(b)], and 
then we retrieve the MS byte of the return address and push it onto the 
stack [Figure L4-15(c)]. 

Finally, we execute the RTS (“return from subroutine”) instruc¬ 
tion. This automatically pops the return address from the top of the 
stack, as shown in Figure L4-15(d), and returns us to the testbench 
program, which will then call the its DISPNUM subroutine to display 
the result. 


Creating and Debugging the 
_ADD Routine 

Invoke the assembler, enter the _add subroutine as shown above, and 
save it in a file called int-add-2-byte-vl.asm. In the not-so-distant future, 
we are going to insert this file into our main testbench program, but first 
we need to make sure that we’ve entered it correctly (without any “fin¬ 
ger-slips”) and that it will assemble without errors. 

If you try clicking the assemble button, however, the assembler will 
immediately inform you that you need a . ORG statement. And if you fix 
this, you’ll run into another problem. In fact, we need to “wrap” the 
_ADD routine with a couple of statements as follows: 
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Figure L4-15. Pushing the return address onto the stack. 
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.ORG $4000 

{The _ADD 

subroutine goes here} 

MSG_001: 

.BYTE 

DISPERR: 

RTS 


.END 


That is, in order to make the assembler happy, we need a . ORG statement 
to kick everything off, a . END statement to terminate things, and two 
labels (msg_001 and disperr) to satisfy the external references made 
by the _add routine. 

Now, try clicking the assemble button again. Any errors you detect 
from here on are your own, so track them down and debug them until 
you receive a “Your file was assembled without any errors” message. 

Once you have fully debugged your _add routine, strip out the 
“wrapping statements” we added above, and use the assembler’s File > 
Save command to save this file one last time. 


If you wish, you can launch multiple instantiations of the assembler. Every time you use the Tools > 
Assembler command (or click the assembler toolbar icon), a new copy of the assembler will appear. This can 
be very useful for “power users” who wish to edit different files in different assembler windows, but be careful 
not to open the same file in multiple copies of the assembler (otherwise things will become very confusing very 
quickly). 


Modifying the Testbench to Call the 
ADD Routine 


Use the assembler’s File > Open command to open up the skeleton- 
lab4.asm file you created in Lab 4a, and then use the File > Save As com¬ 
mand to save this as lab4b.asm. 

Modify the body of the testbench program to call the _add routine 
as follows (the change is highlighted in gray): 


MAINLOOP: 

JSR 

[GETNUM] 

# 

Get 1st 

16-bit number (NUMA) 


JSR 

[GETNUM] 

# 

Get 2nd 

16-but number (NUMB) 


JSR 

[_ADD] 

# 

Add NUMA and NUMB together 


JSR 

[DISPNUM] 

# 

Display 

16-bit number from stack 


Now, scroll down this file until the end of the subroutines to find the 
comment line that reads as follows: 

########## This is where the math subroutine will go 






308 


LABS FOR CHAPTER 4 INTEGER ARITHMETIC 


Delete this comment and leave your cursor at the beginning of this line, 
then use the assembler’s Insert > Insert File command, locate the int- 
add-2-byte-vl.asm source file you just created in the ensuing dialog, and 
click the Open button to insert the contents of that file into this version 
of the testbench program. 

Use the File > Save command to save this modified version of 
the testbench, and then click the assemble button to assemble it. If all 
goes well, there shouldn’t be any problems; otherwise, it’s up to you 
to isolate any bugs and fix them (sorry, we don’t have a magic wand 
for this). 


Using the Testbench to Test the Routine 

Click the On/Off button on the front panel to power-up the calculator, 
use the Memory > Load RAM command to load the labdb.ram file into 
the calculator’s memory, and click the Run button to set the program 
running. 

After clearing the display, the program loops around waiting for 
you to input your first number. As a first test, click on the following se¬ 
quence of keys: 

3, A, 6, C, Lnter 6, 2, 1, 2, Lnter 

As we’ve discussed (ad infinitum), the program will add these numbers 
together and present the result on the main display, which will now show 
the following: 

3A6C 6212 = 9C7E 

The program now waits for you to click any key, at which point it will 
clear the main display and wait for you to enter another two numbers. 
Experiment with different values to make sure that this routine works as 
expected. As another test, try clearing the display and entering the fol¬ 
lowing sequence of keys: 

“F,” “F,” “F,” “E,” “Enter” “0,” “0,” “0,” “ 1,” “Enter” 

This should result in the following characters appearing on the main 
display: 


FFFE 0001 = FFFF 
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The result, FFFF, is the largest value we can hold in a 2-byte (16-bit) 
field. Now, try clearing the display and entering the following sequence 
of keys: 

“F,” “F,” “F,” “E,” “Enter” “0,” “0,” “0,” “2,” “Enter” 

The result is too big to fit in our 2-byte field, so the C (carry) flag will be 
set to 1, the error check should call the disperr subroutine, and the fol¬ 
lowing message should appear on the main display: 

ERROR: Carry = 1 


Further Modifications 


There are a variety of little “tweaks” you could make to improve the aes¬ 
thetics of our testbench program; for example: 

• When the program is ready for you to input a number, it could 
write a question mark “?” character to the main display. [When 
you start entering that number, you could write a $12 (“Back”) 
code to the display; this will cause the display to clear the last 
(right-most) character—the “?”—and shift any remaining char¬ 
acters one place to the right.] 

• You could write “$” characters to the main display so as to make 
it obvious that the numerical values are in hexadecimal. 

• You could write a “-I-” character to the display between inputting 
the first and second numbers so as to make clear the math opera¬ 
tion that is being performed. Taking this and the previous point 
together, the display resulting from adding two numbers (say, 
$1234 and $4321) together would now appear as follows: 


$1234-h $4321 = $5555 
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Creating a 16-b1t 
SUBTRACT Subroutine 


Objective: To create a general-purpose subroutine that can subtract 

one 2-byte (16-bit) unsigned binary number from another. 
Duration: Approximately 35 minutes. 


The 16-bit _SUB Subroutine Itself 

The _SUB subroutine is very similar to the _ADD routine we created in 
Lab 4b. This new routine is presented below in its entirety, followed by 
notes on the differences between this routine and its _add counterpart. 
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########## 

Get return address 

from stack and store it 

_SUB; 

POPA 


# 

Retrieve MS byte of return 


STA 

[_SB_RADD] 

# 

address from stack and store it 


POPA 


# 

Retrieve LS byte of return 


STA 

[_SB_RADD+1 

1 # 

address from stack and store it 

########## 

Get subtrahend and . 

minuend from stack 

_SB_GNUM: 

POPA 


# 

Retrieve MS byte of subtrahend 


STA 

[_SB_NUMB] 

# 

from stack and store it 


POPA 


# 

Retrieve LS byte of subtrahend 


STA 

[_SB_NUMB+1 

1 # 

from stack and store it 


POPA 


# 

Retrieve MS byte of minuend from 


STA 

[_SB_NUMA] 

# 

stack and store it 


POPA 


# 

Retrieve LS byte of minuend from 




# 

stack Sc leave it in the ACC 

########## 

Perform 

the subtraction 

_SB_DOIT: 

SUB 

[_SB_NUMB+1 

1 # 

Sub LS byte of subtrahend from ACC 


PUSHA 


# 

and push LS difference onto stack 


LDA 

[_SB_NUMA] 

# 

Load ACC with MS byte of minuend 




# 

from temp location 


SUBC 

[_SB_NUMB] 

# 

Sub MS byte of subtrahend from ACC 


PUSHA 


# 

w (borrow) and push MS diff to stack 

########## 

Make sure there isn't a borrow out from the MS subtraction 

_SB_CHK; 

JC 

[_SB_RET] 

# 

If carry flag = 1 jump to return 


BLDX 

MSG_002 

# 

Load X reg with addr of message 


JSR 

[DISPERR] 

# 

Jump to display error subroutine 




# 

(which terminates the program) 

########## 

Return ■ 

to main program 


_SB_RET: 

LDA 

[_SB_RADD+1 

1 # 

Load ACC with LS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


LDA 

[_SB_RADD] 

# 

Load ACC with MS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


RTS 


# 

That's it, exit the subroutine 

########## 

Reserve 

temp locations 

for this subroutine 

_SB_RADD: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the return address 

_SB_NUMA: 

.BYTE 


# 

Reserve 1-byte temp location for 




# 

the MS byte of the minuend 

_SB_NUMB; 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the subtrahend 

########## 

This is 

the end of 

the 

_SUB subroutine 

#- 

— 


— 

-# 
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The differences between the _SUB routine and its _add cousin 
from the previous lab are as follows: 

• The labels are prefixed by _SB_. 

• When we actually perform the subtraction at label _SB_D0IT, 
the ADD instruction is replaced with a SUB, whereas the ADDC 
(“add with carry”) is replaced by a SUBC (“subtract with 
carry/borrow”). 

• With regard to the error test at label _SB_CHK, a 1 in the C (carry 
flag) indicates that there were no problems, whereas a 0 indicates a 
borrow condition (in which case the index register is loaded with 
the address associated with label MSG_0 02 ). In turn, this indicates 
that we have tried to subtract a bigger number from a smaller one, 
which results in a negative value. For the purposes of this lab, how¬ 
ever, we are assuming the use of unsigned binary numbers, which 
means that we don’t have any way of representing negative values. 


When we subtract a larger number from a smaller number, the result is a borrow-out of the higher- 
order bit, and we say that an underflow condition has occurred. 

Thus, as opposed to flagging our error using the string associated with the msg_0 02 label, we could have used 
the string associated with the msg_004 label had we so desired (refer to Lab 4a for details on the various mes¬ 
sage strings). 


Creating and Debugging the 
SUB Routine 


Invoke the assembler, enter the _SUB subroutine as shown above, and 
save it in a file called int-sub-2-byte-vl.asm. 

As before, in order to perform preliminary testing on this routine, 
we need a . ORG statement to kick everything off, a . end statement to 
terminate things, and two labels (msg_002 and disperr) to satisfy the 
external references made by the _SUB routine. Thus, we need to “wrap” 
our routine with a couple of statements as follows: 



.ORG $4000 

{The _SUB 

subroutine goes here} 

MSG_002: 

.BYTE 

DISPERR: 

RTS 


.END 
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Now, try clicking the assemble button and track down and debug 
any errors until you receive a “Your file was assembled without any er¬ 
rors” message. Once you reach this point, strip out the “wrapping state¬ 
ments” we added above and use the assembler’s File > Save command to 
save this file one last time. 


Modifying the Testbench to Caii the 
_SUB Routine 

Use the assembler’s File > Open command to open up the skeleton- 
lab4.asm file you created in Lab 4a, and then use the File > Save As com¬ 
mand to save this out as lab4c.asm. 

Modify the body of the testbench program to call the _SUB routine 
as follows (the change is highlighted in gray): 

MAINLOOP: JSR [GETNUM] # Get 1st 16-bit number (NOMA) 

JSR [GETNUM] # Get 2nd 16-but number (NUMB) 

JSR [_SUB] # Subtract NUMB from NUMA 

JSR [DISPNUM] # Display 16-bit number from stack 

Now, scroll down the file until the end of the subroutines to find the 
comment line that reads as follows: 

########## This is where the math subroutine will go 

Delete this comment and leave your cursor at the beginning of this line, 
then use the assembler’s Insert > Insert File command, locate the int- 
sub-2-byte-vl.asm source file you just created in the ensuing dialog, and 
click the Open button to insert the contents of that file into this version 
of the testbench program. 

Use the File > Save command to save this modified version of the 
testbench, and then click the assemble button to assemble it. 

Using the Testbench to Test the Routine 

Click the On/Off button on the front panel to power-up the calculator, 
use the Memory > Load RAM command to load the lab4c.ram file into 
the calculator’s memory, and click the Run button to set the program 
running. 
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As usual, once the display has been cleared, the program will loop 
around, waiting for you to input your first number. As a first test, click 
on the following sequence of keys: 

“8,” “3,” “5,” “1,” “Enter” “6,” “2,” “2,” “0,” “Enter” 

Unless something totally unforeseen occurs, the program will subtract 
the second number from the first and present the result on the main dis¬ 
play, which will now show the following: 

8351 6220 = 2131 

The program now waits for you to click any key, at which point it will 
clear the main display and wait for you to enter another two numbers. 
Experiment with different values to make sure that this routine works as 
expected. 

In order to test the error-checking mechanism, clear the display 
and enter the following sequence of keys: 

“0,” “1,” “2,” “3,” “Enter” “0,” “1,” “2,” “3,” “Enter” 

This should result in the following characters appearing on the main 
display: 

0123 0123 = 0000 

The result, 0000, is the smallest value we can hold in a 2-byte (16-bit) 
unsigned field. Now, clear the display once more and enter the following 
sequence of keys: 

“0,” “1,” “2,” “3,” “Enter” “0,” “1,” “2,” “4,” “Enter” 

The result (minus 1) is too small to fit in our 2-byte field, so the C (car¬ 
ry) flag will be cleared to 0, the error check should call the disperr sub¬ 
routine, and the following message should appear on the main display: 


ERROR: Borrow = 0 
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Creating a 16-b1t 
NEGATE Subroutine 


Objective: 


Duration: 


To create a general-purpose subroutine that can negate a 
2-byte (16-bit) signed binary number (that is, convert a 
positive value into its negative counterpart, and vice 
versa). 

Approximately 30 minutes. 


The 16-bit NEG Subroutine Itself 


The easiest way to negate a value is to subtract it from zero, so that’s the 
approach we will take with our _neg subroutine as shown below: 

####################################################################### 


# Name: _NEG # 

# # 

# Function: Negates a 16-bit signed binary value (changes a positive # 

# value into its negative equivalent and vice versa) and # 

# returns a 16-bit result in the range -32,767 through # 

# +32,767. Note that this routine assumes that it will # 

# not be presented with a value of -32,768, and therefore # 

# does not perform an error check for this input value) # 

# # 

# Entry: Top of stack # 

# Most-significant byte of return address # 

# Least-significant byte of return address # 

# Most-significant byte of number to be negated # 

# Least-significant byte of number to be negated # 

# # 

# Exit: Top of stack # 

# Most-significant byte of result # 

# Least-significant byte of result # 

# # 

# Modifies: Accumulator # 

# # 
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# size: 

Program = 37 bytes 


# 

# 

Data 

= 4 bytes 


# 

####################################################################### 

########## 

Get return address from stack and store it 

_NEG: 

POPA 


# 

Retrieve MS byte of return 


STA 

[_NG_RADD] 

# 

address from stack and store it 


POPA 


# 

Retrieve LS byte of return 


STA 

[_NG_RADD+1] 

# 

address from stack and store it 

########## 

Get 2-byte number to 

be negated from stack 

_NG_GNUM: 

POPA 


# 

Retrieve MS byte of number to be 


STA 

[_NG_NUM] 

# 

negated from stack and store it 


POPA 


# 

Retrieve LS byte of number to be 


STA 

[_NG_NUM+1] 

# 

negated from stack and store it 

########## 

Perform 

the subtraction 

_NG_DOIT: 

LDA 

$00 

# 

Load ACC with zero 


SUB 

[_NG_NUM+1] 

# 

Sub LS byte of number from ACC 


PUSHA 


# 

and push LS result onto stack 


LDA 

$00 

# 

Load ACC zero 


SUBC 

[_NG_NUM] 

# 

Sub MS byte of number from ACC w 


PUSHA 


# 

(borrow) and push MS result to stack 

########## 

Return ■ 

to main program 


_NG_RET: 

LDA 

[_NG_RADD+1] 

# 

Load ACC with LS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


LDA 

[_NG_RADD] 

# 

Load ACC with MS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


RTS 


# 

That's it, exit the subroutine 

########## 

Reserve 

temp locations 

for this subroutine 

_NG_RADD: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the return address 

_NG_NUM: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the number to be negated 

########## 

This is 

the end of the 

_NEG subroutine 

#- 

— 

— 

- 

- # 


In fact, this routine is very similar to the _SUB routine we created 
in the previous lab, the main differences being: (a) we only have to re¬ 
trieve and store one 2-byte number from the stack, (b) we subtract this 
number from $0000, and (c) we don’t perform any error checking. 

One key point associated with this routine is that a 2-byte (16-bit) 
unsigned binary number can be used to represent values in the range 
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-32,768 to +32,767. However, this means that is isn’t possible to negate a 
value of-32,768, so this routine assumes that it will only ever be asked to 
negate values in the range -32,767 to +32,767. 

Creating and Debugging 
the _NEG Routine 

Invoke the assembler, enter the _NEG subroutine as shown above, and 
save it in a file called int-neg-2-byte.asm. 

In order to perform preliminary testing, we need to “wrap” this 
routine with an . ORG statement to kick everything off and an . END 
statement to terminate things as follows: 

.ORG $4000 

{The _NEG subroutine goes here} 

.END 


Now, click the assemble button and track down and debug any errors 
until you receive a “Your file was assembled without any errors” mes¬ 
sage. Once you reach this point, strip out the “wrapping statements” we 
added above and use the assembler’s File > Save command to save this 
file one last time. 

Modifying the Testbench to Caii 
the _NEG Routine 

Use the assembler’s File > Open command to open up the skeleton- 
lab4.asm file you created in Lab 4a, and then use the File > Save As com¬ 
mand to save this out as lab4d.asm. 

Modify the body of the testbench program to delete one of our calls 
to the GETNUM subroutine and to add a call the _NEG routine as follows 
(these changes are highlighted in gray): 


MAINLOOP: JSR [GETNUM] # Get a 16-bit number 

-JSR- [GETNUM] -# G e t 2nd 16-but numb e r (NUMB) 

JSR [_NEG] # Negate the value 

JSR [DISPNUM] # Display 16-bit number from stack 
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Now, scroll down the file until the end of the subroutines to find the 
comment line that reads as follows: 

########## This is where the math subroutine will go 

Delete this comment and leave your cursor at the beginning of this line, 
then use the assembler’s Insert > Insert File command, locate the int- 
neg-2-byte.asm source file you just created in the ensuing dialog, and 
click the Open button to insert the contents of that file into this version 
of the testbench program. 

Use the File > Save command to save this modified version of the 
testbench, and then click the assemble button to assemble it. 

Using the Testbench to Test the Routine 

Click the On/Off button on the front panel to power-up the calculator, 
use the Memory > Load RAM command to load the lab4d.ram file into 
the calculator’s memory, and click the Run button to set the program 
running. 

Once the display has been cleared, the program will loop around, 
waiting for you to input a single 4-digit hexadecimal number. As a first 
test, click on the following sequence of keys: 

“0,” “0,” “0,” “0,” “Enter” 

The program will subtract this value from zero, and 0-0 = 0, which 
means that the main display should now show the following: 

0000 = 0000 

The program now waits for you to click any key, at which point it will 
clear the main display and wait for you to enter another number. Experi¬ 
ment with different values to make sure that this routine works as ex¬ 
pected; for example, clear the display and try the following sequence 
of keys: 

“0,” “0,” “0,” “1,” “Enter” 

This should result in the following characters appearing on the main 
display: 


0001= EEEE 
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This is just what we expect, because $FFFF equates to -1 in the signed 
binary number format. Similarly, if you clear the display and enter the 
following sequence of keys, 

this should result in the following characters appearing on the main 
display: 

FFFE = 0002 

Again, this is what we expect, because $FFFE equates to -2 in the signed 
binary number format. Don’t forget that, should you wish to check the 
results by hand, all you have to do is generate the twos complement of 
the number to be negated. As we discussed in Chapter 4, the easiest way 
to do this is to copy the bits up to and including the first 1, and then 
invert the remaining bits. Eor example, consider how we would use this 
technique to generate the twos complement of $EEEE as shown in 
Eigure L4-16. 


Flexadecimal value 


> F F F E 


Binary equivalent -► 

Copy up to and 
including the first "1" 

Invert the remaining bits _^ 

(Os to 1s and 1 s to Os) 

Hexadecimal result - 




1111 

1111 

1111 

1110 



--10 



0000 

0000 

0000 

0010 



> 0 0 0 2 


Figure L4-16. Generating twos complement values by hand to check the 
results. 












Lab 

4e 


Objective: To modif)^ our general-purpose _ADD and _SUB 

routines to work with signed binary numbers; that is, to 
check the O (overflow) flag. 

Duration: Approximately 35 minutes. 


Testing for -32,768 

Based on the discussions of signed binary numbers presented in Chapter 
4, we know that a 2-byte (16-bit) signed binary number can be used to 
represent values in the range -32,768 through -1-32,767 (Figure L4-17). 

The point is that both the _add and _SUB routines can easily gen¬ 
erate a value of -32,768. For example, if we were to perform the opera¬ 
tion $8001 -t- SFFFF [which equates to -32,767 -I- (-1) in decimal], the re¬ 
sult would be $8000 (that is, -32,768 in decimal). 

Now this isn’t an issue with the _ADD and _SUB routines per se, but 
it does present us with something of a problem with regard to the _mult 
(“multiply”) and _Div (“divide”) routines we are going to create in Labs 
4f and 4g, respectively. This is because their core algorithms work only 
with positive values, which means that the first thing they do is convert 
any negative quantities into their positive counterparts, perform the 
multiplication or division operation, and then correct the sign of the 
result. 

The problem, of course, is that if these routines are presented with 
a value of-32,768, there is no way we can negate it, because the maxi¬ 
mum positive value our 2-byte field can support is -1-32,767. The solution 
is to make a decision that we will work only with numbers in the range 
$8001 through $7FFF (that is -32,767 through +32,767 in decimal). In 
turn, this means that once we’ve performed an operation such as an ad- 


01000010101101010010010010001101100000 EIE 
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Binary Hex Decimal 


0000 

0000 

0000 

0000 

0000 


+ 0 

0000 

0000 

0000 

0001 

0001 


+ 1 

0000 

0000 

0000 

0010 

0002 


+ 2 

0111 

1111 

1111 

1110 

7FFE 

+ 32, 

, 766 

0111 

1111 

1111 

1111 

7FFF 

+ 32, 

, 767 

1000 

0000 

0000 

0000 

8000 

-32, 

.768 

1000 

0000 

0000 

0001 

8001 

-32, 

, 767 

1000 

0000 

0000 

0010 

8002 

-32, 

, 766 

1111 

1111 

1111 

1101 

FFFD 


-3 

1111 

1111 

1111 

1110 

FFFE 


-2 

1111 

1111 

1111 

1111 

FFFF 


-1 


Figure L4-17. Signed binary numbers in a 2-byte field. 


dition or subtraction using our _ADD or _SUB routines, respectively, we 
need to check to ensure that the result is not $8000 (-32,768 in decimal). 


Devising a subroutine to check for -32,768 


If we wished, we could add tests for -32,768 directly into the _add and 
_SUB routines themselves. As an alternative, we can create a special 
CHK2NEG (“check if too negative”) subroutine to perform this task for us 
as shown below: 


########## Start of CHK2NEG subroutine 

########## Retrieve a 16-bit binary value from the stack and test it. 
########## If -32,768, call DISPERR, else return number intact. 


########## 

Pop the 

return address 

off the stack and save it 


CHK2NEG: 

POPA 


# 

Pop the MS byte of return 

address 


STA 

[_CN_RADD] 

# 

off the stack and store 

it 


POPA 


# 

Pop the LS byte of return 

address 


STA 

[_CN_RADD+1] 

# 

off the stack and store 

it 

########## 

Pop the 

number to be 

tested off the stack 


_CN_GNUM: 

POPA 


# 

Pop MS byte of number off 

the 


STA 

[_CN_NUM] 

# 

stack and store it 



POPA 


# 

Pop LS byte of number off 

the 


STA 

[_CN_NUM+1] 

# 

stack and store it 



########## Push a copy of the number back onto the stack 
_CN_PNUM: PUSHA # Push LS byte of number onto stack 

LDA [_CN_NUM] # Retrieve MS byte of number 

PUSHA # and push it onto the stack 
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########## Check the MS byte to see if it's equal to $80 
_CN_CKMS: CMPA $80 # Compare contents of ACC to $80 

JNZ [_CN_RET] # If not equal we're OK so return 

########## Check the LS byte to see if it's equal to $00 


_CN_ 

_CKLS: 

LDA 

[_CN_NUM+1] 

# 

Load ACC with LS byte of number 



CMPA 

$00 

# 

Compare contents of ACC to $00 



JNZ 

[_CN_RET] 

# 

If not equal we're OK so return 

########## 

Call 

the error message 

display subroutine 

_CN_ 

_DERR: 

BLDX 

MSG_009 

# 

Load X reg with addr of message 



JSR 

[DISPERR] 

# 

Jump to display error subroutine 





# 

(which terminates the program) 


########## Return gracefully from this subroutine 

_CN_RET: LDA [_CN_RADD+1] # Get LS byte of return address from 

PUSHA # temp location and push onto stack 

LDA [_CN_RADD] # Get MS byte of return address from 

PUSHA # temp location and push onto stack 

RTS # Return from this subroutine 

########## Reserve temp locations for this subroutine 

_CN_RADD: .2BYTE # 2-byte temp location used to store 

# the return address for this routine 

_CN_NUM: .2BYTE # 2-byte temp location to store 

# the number we're checking 
########## End of CHK2NEG subroutine 


As we see, there is nothing too surprising here. The first thing we 
do when we enter this subroutine at label CHK2NEG is to pop the return 
address off the stack and store it in a temporary location. 

Next, at label _CN_GNUM (“get number”) we pop the 2-byte num¬ 
ber to be tested off the stack and store it in a temporary location. This 
leaves the least-significant (LS) byte in the accumulator, which is just 
where we want it when we arrive at label _gn_pnum (“put number”). 
This is where we push a copy of the 2-byte number back onto the stack, 
because if the number passes our tests, then we want it to be available to 
whichever part of the program requested this check when we eventually 
return from this subroutine. 

The act of pushing a copy of the number back onto the stack leaves 
a copy of the MS byte of the number in the accumulator. By some 
strange quirk of fate, this is just what we want when we arrive at label 
_GN_CKMS (“check MS byte”), at which point we compare the value in 
the accumulator to $80. If the values are not equal (in which case the Z 
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(zero) flag will be cleared to its “false” state), we know there isn’t a prob¬ 
lem, so we use the JNZ (“jump if not zero”) instruction to immediately 
jump to the _CN_RET (“return”) label. 

Alternatively, if the MS byte of the number does equal $80, then we 
potentially have a problem depending on whether or not the value in the 
LS byte equals $00. Thus, at label _CN_CKLS (“check LS byte”), we load a 
copy of the LS byte into the accumulator and compare it to $00. Once 
again, if the values are not equal (in which case the Z (zero) flag will be 
cleared to its “false” state), we know there isn’t a problem, so we use the 
JNZ (“jump if not zero”) instruction to jump to the _CN_RET (“return”) 
label. Otherwise, we fall through to label _cn_derr (“display error”), at 
which point we load the index register (X) with the address of an appro¬ 
priate error message and jump to the disperr (“display error”) subrou¬ 
tine, which will display the error message and terminate the program. 

And, of course, if there is no error, then when we arrive at label 
_CN_RET (“return”), we push a copy of the return address back onto the 
stack and then use an RTS (“return from subroutine”) instruction to take 
us back to the main program. 

Creating and debugging the routine 

Invoke the assembler, enter the CHK2NEG subroutine as shown above, 
and save it in a file called int-check-32768.asm. 

As before, in order to perform preliminary testing on this routine, 
we need a . ORG statement to kick everything off, a . END statement to 
terminate things, and two labels (msg_009 and DISPERR) to satisfy the 
external references made by the CHK2NEG routine. Thus, we need to 
“wrap” our routine with a couple of statements as follows: 

.ORG $4000 

{The CHK2NEG subroutine goes here} 

MSG_0 09: .BYTE 
DISPERR: RTS 

.END 

Now, try clicking the assemble button and track down and debug 
any errors until you receive a “Your file was assembled without any er¬ 
rors” message. Once you reach this point, strip out the “wrapping state¬ 
ments” we added above and use the assembler’s File > Save command to 
save this file one last time. 




TESTING THE MODIFIED 


327 


ADD ROUTINE 


Modifying the _ADD Routine 

Use the assembler’s File > Open command to open up the int-add-2- 
byte-vl.asm file you created in Lab 4b, and then use the File > Save As 
command to save this as int-add-2-byte-v2.asm. 

Now, scroll down through this routine until you reach the _AD_CHK 
label, which is where we originally checked the carry flag to see if there 
was a carry-out from the addition of the two MS bytes. Of course, that 
was when we were considering the values to be added as unsigned binary 
numbers. Now that we are considering the values to be signed binary 
numbers, we need to modify this test to check the overflow flag, and also 
to check for a negative result of-32,768, as discussed in the previous sec¬ 
tion. So, make the changes shown below and save this file for future use: 



















Lcjcicl j. WJ-Lli 

(a.cU.L o£ luetaiDctye 




yf 

(which terminates—the program) 


########## Make sure there isn't an overflow from the MS addition 
_AD_CHKO: JNO [_AD_CHKN] # If no overflow jump to next test 

BLDX MSG_003 # Load X reg with addr of message 

JSR [DISPERR] # Jump to display error subroutine 

# (which terminates the program) 


########## Call the CHK2NEG subroutine to test for -32,768 
_AD_CHKN: JSR [CHK2NEG] # Call the CHK2NEG subroutine 


Observe that we’ve deleted nine bytes from our original code and 
added twelve bytes back in. Now, consider the following comment in the 
header at the beginning of the _ADD routine: 


Size: Program = 50 bytes 

Based on the changes discussed above, you need to change the val¬ 
ue associated with this comment from 50 to 53 bytes. 


Testing the Modified _ADD Routine 

Use the assembler’s File > Open command to open up the labdb.asm file 
you created in Lab 4b, and then use the File > Save As command to save 
this as lab4e-add.asni. 




328 


LABS FOR CHAPTER 4 INTEGER ARITHMETIC 


Scroll down the file until you find the start of the original _ADD 
subroutine, delete this routine in its entirety, and leave the cursor where 
the routine used to be. 

Now use the Insert > Insert File command to insert the int-add-2- 
byte-v2.asm file that contains the new version of our _add subroutine. 
Then use the Insert > Insert File command once more to insert the int- 
check-32768.asm file containing the CHK2NEG subroutine we created at 
the beginning of this lab. 

Click the assemble button. Hopefully, there won’t be any errors, 
but if there are, track them down and debug them until you receive a 
“Your file was assembled without any errors” message. 

Click the On/Offbutton on the front panel to power-up the calcu¬ 
lator, use the Memory > Load RAM command to load the lab4e-add.ram 
file into the calculator’s memory, and click the Run button to set the 
program running. 

After clearing the display, the program loops around, waiting for 
you to input your first number. As a first test, let’s try adding two small 
numbers together, so click on the following sequence of keys: 

“0,” “0,” “0,” “6,” “Enter” “0,” “0,” “0,” “2,” “Enter” 

The main display should now show the following: 

0006 0002 = 0008 

This shouldn’t be too surprising to us, because 6 + 2 does indeed equal 8. 
Now let’s see what happens if we add a small negative number to a larger 
positive one as follows. Click any key to clear the display, and then click 
on the following sequence of keys: 

“0,” “0,” “0,” “6,” “Enter” “F,” “F,” “F,” “E,” “Enter” 

As $FFFE equates to -2 when we’re dealing with signed binary numbers, 
the main display should now show the following: 

0006 FFFE = 0004 

Again, this is what we expect, because 6 + (-2) does equal 4. Let’s get a 
little more daring, and try adding a larger negative number to a smaller 
positive one. Click any key to clear the display, and then click on the fol¬ 
lowing sequence of keys: 

“0,” “0,” “0,” “6,” “Enter” “F,” “F,” “F,” “8,” “Enter” 
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As $FFF8 equates to -8, the main display should now show the following: 

0006 FFF8 = FFFE 

As we discussed a little earlier, the result ($FFFE) equates to -2, which is 
what we expect because 6 + (-8) does equal -2. This means that we can 
change the sign of the result without triggering the overflow flag if we 
perform a legitimate operation. Now let’s see what happens if the sign 
changes as a result of an illegitimate operation. Click any key to clear the 
display, and then click on the following sequence of keys: 

“7,” “F,” “F,” “F,” “Enter” “0,” “0,” “0,” “2,” “Enter” 

In this case, the $7FFF equates to 32,767, which is the largest positive val¬ 
ue we can hold in our 2-byte signed binary number. Adding 2 to this will 
give a result of $8001, which equates to -32,767, and which will trigger 
an overflow condition. When our test in the _ADD subroutine detects 
that the O (overflow) flag has been set, it will call the disperr subrou¬ 
tine, which will display the following error message and terminate the 
program: 

ERROR: Overflow 

As a final test, rerun the program by clicking the Run button and then 
click on the following sequence of keys: 

“8,” “0,” “0,” “1,” “Enter” “F,” “F,” “F,” “F,” “Enter” 

As we discussed at the beginning of this chapter, $8001 -I- $FFFF = $8000 
[which equates to -32,767 -I- (-1) = -32,768 in decimal]. This is, of 
course, a perfectly legitimate operation, so the overflow flag won’t be 
triggered. However, the _add subroutine calls the CHK2NEG subroutine, 
and when it detects this value it will call the DISPERR subroutine, which 
will display the following error message and terminate the program: 

ERROR: -32,768 


Modifying the _SUB Routine 

Use the assembler’s File > Open command to open up the int-sub-2- 
byte-vl.asm file you created in Lab 4c, and then use the File > Save As 
command to save this as int-sub-2-byte-v2.asm. 
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Now, scroll down through this routine until you reach the 
_SB_CHK label, which is where we originally checked the carry flag to see 
if there was a borrow-out from the subtraction of the two MS bytes. 

Once again, that was when we were considering the values to be added as 
unsigned binary numbers. Now that we are considering the values to be 
signed binary numbers, we need to modify this test to check the overflow 
flag, and also to check for a negative result of-32,768. So, make the 
changes shown below and save this file for future use: 


########## Make sure there isn't a borrow out from the MS subtraction 


_SB_CHK: 

—je- 

-[_SB_RET]- 

—#- 

~T± —carry—flag—=— 

“jump—Lo reLurn 









— 

(which—herminates 



########## Make 
_SB_CHKO: JNO 

BLDX 
JSR 


sure there isn't an overflow from the MS subtraction 
[_SB_CHKN] # If no overflow jump to next test 
MSG_003 # Load X reg with addr of message 

[DISPERR] # Jump to display error subroutine 

# (which terminates the program) 


########## Call the CHK2NEG subroutine to test for -32,768 
_SB_CHKN: JSR [CHK2NEG] # Call the CHK2NEG subroutine 


As before, observe that we’ve deleted nine bytes from our original 
code and added twelve bytes back in. This means that you need to 
change the value associated with the Size : Program = 50 bytes 
comment in the header for the _SUB routine from 50 to 53 bytes. 


Testing the Modified _SUB Routine 

Use the assembler’s File > Open command to open up the labdc.asm file 
you created in Lab 4c, and then use the File > Save As command to save 
this as lab4e-sub.asm. 

Scroll down the file until you find the start of the original _SUB 
subroutine, delete this routine in its entirety, and leave the cursor where 
the routine used to be. 

Now use the Insert > Insert File command to insert the int-sub-2- 
byte-v2.asm file that contains the new version of our _SUB subroutine. 
Then use the Insert > Insert File command once more to insert the int- 
check-32768.asm file containing the CHK2NEG subroutine we created at 
the beginning of this lab. 
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Click the assemble button. As usual, we hope that there won’t be 
any errors, but if there are, track them down and debug them until you 
receive a “Your file was assembled without any errors” message. 

Click the On/Off button on the front panel to power-up the calcu¬ 
lator, use the Memory > Load RAM command to load the lab4e-sub.ram 
file into the calculator’s memory, and click the Run button to set the 
program running. 

As soon as it’s cleared the display, the program loops around, wait¬ 
ing for you to input your first number. As a first test, let’s try subtracting 
a small positive number from a larger one, so click on the following se¬ 
quence of keys: 

“0,” “0,” “0,” “6,” “Enter” “0,” “0,” “0,” “2,” “Enter” 

The main display should now show the following: 

0006 0002 = 0004 

And, of course, this is what we expect, because 6-2 does equal 4. Now 
let’s see what happens if we subtract a negative number from a positive 
one as follows. Click any key to clear the display, and then click on the 
following sequence of keys: 

“0,” “0,” “0,” “6,” “Enter” “F,” “F,” “F,” “E,” “Enter” 

As $FFFE equates to -2 when we’re dealing with signed binary numbers, 
the main display should now show the following: 

0006 FFFE = 0008 

Again, this is what we expect, because 6 - (-2) equates to 6 -I- 2, which of 
course returns a result of 8. Let’s get a little more daring, and try sub¬ 
tracting a bigger number from a smaller one. Click any key to clear the 
display, and then click on the following sequence of keys: 

“0,” “0,” “0,” “6,” “Enter” “0,” “0,” “0,” “8,” “Enter” 

Of course 6 - 8 = -2, and as the 2-byte hexadecimal equivalent to -2 is 
$FFFE, the main display should now show the following: 

0006 0008 = FFFE 

As with the _ADD function, this means that our _SUB routine can change 
the sign of the result without triggering the overflow flag if we perform a 
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legitimate operation. Now let’s see what happens if the sign changes as a 
result of an illegitimate operation. Click any key to clear the display, and 
then click on the following sequence of keys: 

“8,” “0,” “0,” “1,” “Enter” “0,” “0,” “0,” “2,” “Enter” 

As we know, the $8001 equates to -32,767. If we now attempt to subtract 
2 from this value, then as opposed to a result of-32,769 (which cannot 
be represented in a 2-byte field), we’ll actually end up with a result of 
$7FFF. This equates to -t-32,767, and the fact that we’ve performed an il¬ 
legitimate operation will trigger an overflow condition. When our test in 
the _SUB routine detects that the O (overflow) flag has been set, it will 
call the DISPERR subroutine, which will display the following error mes¬ 
sage, and terminate the program: 

ERROR: Overflow 

As a final test, rerun the program by clicking the Run button and then 
click on the following sequence of keys: 

“8,” “0,” “0,” “1,” “Enter” “0,” “0,” “0,” “1,” “Enter” 

In this case, $8001 - $0001 = $8000 (which equates to -32,767 - I = 
-32,768 in decimal). In this case, the fact this is a perfectly legitimate op¬ 
eration means that the overflow flag won’t be triggered. However, the 
_SUB routine also calls the CHK2NEG subroutine, and when it detects this 
value it will call the DISPERR subroutine, which will display the follow¬ 
ing error message and terminate the program: 


ERROR: -32,768 
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Creating a 16-b1t 
MULTIPLY Subroutine 


Objective: To create a general-purpose subroutine that can multiply 

two 2-byte (16-bit) signed binary number together and 
return a 2-byte result. 

Duration: Approximately 50 minutes. 


A Little Thought Experiment 

In order to wrap our brains around the way in which our multiplication 
routine works, we’ll first perform a little thought experiment. Let’s as¬ 
sume we are working with a really simple computer from the days of 
yore that is based on a 4-bit data bus and 4-bit memory locations. If we 
are playing with signed binary numbers, then a 4-bit field (known as a 
nybble) can be used to represent sixteen values in the range -8 through 
+7 (Figure L4-18). 

Now let’s assume that we wish to use the shift-and-add technique 
discussed in Chapter 4 to perform the multiplication operation -3 X +2 
= -6. Initially, we can visualize the way in which this takes place as illus¬ 
trated in Figure L4-19. 

As we noted in Chapter 4, the shift-and-add technique works only 
with positive values, so the first thing we have to do is to negate the nega¬ 
tive multiplier (by taking its twos complement) and generate its positive 
counterpart. (If the multiplicand had been negative, we would have had 
to invert this also.) 

Next, we generate the four partial products. If there is a 0 in the 
multiplier, the corresponding partial product is all Os; alternatively, if 
there is a 1 in the multiplier, the corresponding partial product is a copy 
of the multiplicand. 
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Figure L4-18. Signed binary values in a 4-bit field. 


All of the partial products are now added together to give an 8-bit 
(2-nybble) result. However, due to the fact that we have made the deci¬ 
sion to work only with 4-bit values, we need to discard the most-signifi¬ 
cant nybble (it’s our responsibility to check that the result of the multi¬ 
plication is small enough to fit in a 4-bit field). 

Finally, since this particular example involved multiplying a posi¬ 
tive value by a negative one, we have to correct the sign by negating the 
result. 

Some cunning tricks 

Now let’s consider the actions shown in Figure L4-19 in a little more de¬ 
tail. With the exception of the first partial product, the rest are split 
across two 4-bit nybbles. This means that, if we performed the multipli¬ 
cation as implied in this illustration, we’d have to split the multiplicand 
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Figure L4-19. Visualizing a simple 4-bit multiplication. 


in a different place for each partial product, shift the two resulting frag¬ 
ments by different amounts, and perform two separate additions. We 
could certainly use this technique, but we would ideally prefer a method 
that could achieve the same effect with fewer instructions and less hassle. 

Fortunately, there are some cunning tricks we can play (that’s the 
really cool thing about working at the assembly language level—there are 
always interesting ways of doing things). For example, let’s assume that we 
start off by reserving a 4-bit nybble for our multiplicand and two 4-bit 
nybbles in which to store the 8-bit result from the multiplication. Let’s 
also assume that we initialize the most-significant (MS) of these result nyb¬ 
bles with Os, that we initialize the least-significant (LS) result nybble with a 
copy of the multiplier (already converted into a positive value), and that 
we ensure that the C (carry) flag is loaded with 0 [Figure L4-20(a)]. 

Now we come to perform the first cycle of the multiplication, 
which involves rotating the entire 2-nybble result field one bit to the 
right [Figure L4-20(b)]. (Note that the use of bold text and shaded areas 
in these illustrations is intended only as an aid to understanding the se- 
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(b) Perform a 1-bit rotate (c) Add multiplicand to MS nybble 

Figure L4-20. First cycle of 4-bit multiplication test case. 


quence of events.) Observe that the 0 that used to be in the carry flag 
[from Figure L4-20(a)] is copied into the MS bit of the MS nybble, the 
bit that “falls off the end” of the MS nybble is copied into the MS bit of 
the LS nybble, and the bit that “falls off the end” of the LS nybble is 
copied back into the carry flag. 

This means that the carry flag now contains a copy of bit 0 from the 
original multiplier. We next perform a test on the carry flag to see if it 
contains a 0 or a 1. As it contains a 1 in this case, we add a copy of the 
multiplicand to the current contents of the MS nybble [Figure L4-20(c)]. 
As a by-product of this addition, the carry flag is reloaded with 0. 

Similarly, in the case of the second cycle, we again rotate the 2-nyb¬ 
ble result one bit to the right [Figure L4-21(b)]. As usual, the 0 that used 
to be in the carry flag [from Figure L4-21 (a)] is copied into the MS bit of 
the MS nybble, the bit that “falls off the end” of the MS nybble is copied 
into the MS bit of the LS nybble, and the bit that “falls off the end” of the 
LS nybble is copied back into the carry flag. 

This means that the carry flag now contains a copy of bit 1 from the 
original multiplier. Once again, when we perform a test on the carry flag, 
it contains a 1 in this case, so we add a copy of the multiplicand to the 
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(b) Perform a 1-bit shift/rotate (c) Add multiplicand to MS nybble 

Figure L4-21. Second cycle of 4-bit multiplication test case. 


current contents of the MS nybble [Figure L4-21(c)]. And, as before, the 
carry flag is loaded with 0 as a by-product of this addition. 

When we come to the third cycle of our test case, we commence by 
rotating the 2-nybble result one bit to the right as usual [Figure L4- 
22(b)]. In this case, the bit that “falls off the end” of the LS nybble into 
the carry flag—a copy of bit 2 from the original multiplier—is a 0. This 
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(b) Perform a 1-bit shift/rotate 


(c) Don't do anything (equivalent to add zero ) 


Figure L4-22. Third cycle of 4-bit multiplication test case. 
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Copy of the 
4-bit Multiplicand 



0 I 0 I 0 I 1 I 1 I 0 I 0 I 0 I 

(a) Initial conditions at start of 4th cycle 
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(b) Perform a 1-bit shift/rotate (c) Don't do anything (equivalent to add zero ) 


Figure L4-23. Fourth cycle of 4-bit multiplication test case. 


means that we don’t actually have to do anything, which is the same as 
adding zero to the MS nybble [Figure L4-22(c)]. 

Similarly, with regard to the fourth and final cycle of our test case, 
when we rotate the 2-nybble result one bit to the right, the bit that “falls 
off the end” of the LS nybble into the carry flag—a copy of bit 3 from the 
original multiplier—is a 0 [Figure L4-23(b)]. Once again, this means that 
we don’t have to do anything, which is the same as adding zero to the MS 
nybble [Figure L4-23(c)]. 

Last, but not least, we have to perform a final 1-bit rotate so as to 
leave the penultimate result in the LS nybble (Figure L4-24). 

The reason we refer to this as the penultimate result is that, as per 
the discussions associated with Figure L4-19, we now need to discard the 
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Figure L4-24. Perform one final shift. 
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MS nybble of the result. Also, due to the fact that our example involved 
multiplying a positive value by a negative one, we have to correct the sign 
by negating (taking the twos complement of) the result. 


The 16-bit MULT Subroutine Itself 


Of course, when it comes to our real _MULT subroutine, we intend to 
multiply two 2-byte (16-bit) numbers together. Just to provide a point of 
reference, the names of the main storage locations used in this routine 
are as shown in Figure L4-25. 


####################################################################### 


# Name: _MULT 

# 

# Function: Multiply two 16-bit signed binary numbers together and 
return a 16-bit result in the range -32,767 to +32,767 


Top of stack 

Most-significant byte of return address 
Least-significant byte of return address 
Most-significant byte of second number (multiplicand) 
Least-significant byte of second number (multiplicand) 
Most-significant byte of first number (multiplier) 
Least-significant byte of first number (multiplier) 


# 

# 

# Entry: 

# 

# 

# 

# 

# 

# 

# 

# Exit: 

# 

# 

# 

# Modifies: 

# 

# Size: 

# 

####################################################################### 

########## Get return address from stack and store it 
_MULT: POPA # Retrieve MS byte of return 

STA [_ML_RADD+0] # address from stack and store it 

POPA # Retrieve LS byte of return 

STA [_ML_RADD+1] # address from stack and store it 


Top of stack 

Most-significant byte of result 
Least-significant byte of result 

Accumulator and Index Register 

Program = 211 bytes 
Data = 9 bytes 


(product) 

(product) 


########## Get multiplicand from stack and store it 

_ML_GMAN: POPA # Retrieve MS byte of multiplicand 

STA [_ML_MAND+0] # from stack and store it 

POPA # Retrieve LS byte of multiplicand 
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Copy of the 16-bit multiplicand 
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Figure L4-25. Names of primary storage locations in the real subroutine. 




STA 

[_ML_MAND+1] 

# 

from stack and store it 


########## 

Get multiplier from 

Stack and store it 


_ML_ 

_GMUL: 

LDA 

$00 

# 

Load ACC with 0 and save it to 




STA 

[_ML_RES+0] 

# 

the two MS bytes of the 




STA 

[_ML_RES+1] 

# 

4-byte result 




POPA 


# 

Retrieve MS byte of multiplier 




STA 

[_ML_RES+2] 

# 

from stack and store it 




POPA 


# 

Retrieve LS byte of multiplier 




STA 

[_ML_RES+3] 

# 

from stack and store it 


########## 

Invert 

multiplicand 

if 

necessary (store sign in flag) 


_ML_ 


LDA 

[_ML_MAND+0] 

# 

Load ACC with MS multiplicand 




STA 

[_ML_FLAG] 

# 

and store a copy in the flag 




JNN 

[_ML_IiynjL] 

# 

If positive value, jump to next 

test 





# 

... otherwise ... 




LDA 

$00 

# 

Load ACC with 0 




SUB 

[_ML_MAND+1] 

# 

Subtract (no carry) LS byte of 



STA 

[_ML_MAND+1] 

# 

multiplicand and store the result 



LDA 

$00 

# 

Load ACC with 0 




SUBC 

[_ML_MAND+0] 

# 

Subtract (with carry) MS byte 

of 



STA 

[_ML_MAND+0] 

# 

multiplicand and store the result 

########## 

Invert 

multiplier if 

necessary (XOR sign in flag) 


_ML_ 

_IMUL: 

LDA 

[_ML_FLAG] 

# 

Load the flag 




XOR 

[_ML_RES+2] 

# 

XOR it with MS byte of multiplier 



AND 

%10000000 

# 

Clear bits (except sign) to 0 




STA 

[_ML_FLAG] 

# 

Store the flag away again 




LDA 

[_ML_RES+2] 

# 

Load ACC with MS multiplier 




JNN 

[_ML_DUMY] 

# 

If positive value, jump to next 

part 





# 

... otherwise ... 
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LDA 

$00 

# 

Load ACC with 0 



SUB 

[_ML_RES+3] 

# 

Subtract (no carry) LS byte of 



STA 

[_ML_RES+3] 

# 

multiplier and store the result 



LDA 

$00 

# 

Load ACC with 0 



SUBC 

[_ML_RES+2] 

# 

Subtract (with carry) MS byte of 



STA 

[_ML_RES+2] 

# 

multiplier and store the result 

########## 

Duinmy 

instruction to 

ensure the carry flag contains 0 

_ML_ 

_DUMY: 

ADD 

$00 

# 

Add 0 to ACC (will clear C to 0) 

########## 

Hold 

tight—this is the 

start of the multiplication loop 



BLDX 

17 

# 

Load index reg with the number of 





# 

times we want to go around loop + 1 

_ML_ 

_DOIT: 

JNC 

[_ML_ROT] 

# 

If carry = 0, jump to next rotate 



LDA 

[_ML_RES+1] 

# 

otherwise add the 16-bit 



ADD 

[_ML_MAND+1] 

# 

multiplicand to the MS 16-bits 



STA 

[_ML_RES+1] 

# 

of the result 



LDA 

[_ML_RES+0] 

# 




ADDC 

[_ML_MAND+0] 

# 




STA 

[_ML_RES+0] 

# 


_ML_ 

_ROT: 

LDA 

[_ML_RES+0] 

# 

Rotate the 4-byte (32-bit) result 



RORC 


# 

one bit to the right. Start with 



STA 

[_ML_RES+0] 

# 

the MS byte: _ML_RES+0 



LDA 

[_ML_RES+1] 

# 

Now do _ML_RES+1 



RORC 


# 




STA 

[_ML_RES+1] 

# 




LDA 

[_ML_RES+2] 

# 

Now do _ML_RES+2 



RORC 


# 




STA 

[_ML_RES+2] 

# 




LDA 

[_ML_RES+3] 

# 

Now do _ML_RES+3 



RORC 


# 




STA 

[_ML_RES+3] 

# 


_ML_ 

_ELUP: 

DECX 


# 

Decrement the index register 



JNZ 

[_ML_DOIT] 

# 

If not zero, then do another loop 

########## 

Check 

that the result is less than/egual to 32,767 

_ML_ 

_CHK: 

LDA 

[_ML_RES+0] 

# 

Load MS byte of result 



JNZ 

[_ML_ERR] 

# 

If not zero, jump to display error 



LDA 

[_ML_RES+1] 

# 

Load next byte of result 



JNZ 

[_ML_ERR] 

# 

If not zero, jump to display error 



LDA 

[_ML_RES+2] 

# 

Load next byte of result 



JNN 

[_ML_SIGN] 

# 

Jump if MS bit = 0 

_ML_ 

_ERR: 

BLDX 

MSG_005 

# 

Load X reg with addr of message 



JSR 

[DISPERR] 

# 

Jump to display error subroutine 





# 

(which terminates the program) 
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########## 

Check the flag to see if we have to negate the result 

_ML_ 

_SIGN: 

LDA 

[_ML_FLAG] 

# 

Load the flag byte 



JNN 

[_ML_SAVE] 

# 

Jump if MS bit = 0 



LDA 

$00 

# 

Otherwise invert LS two bytes 



SUB 

[_ML_RES+3] 

# 

of the result by subtracting 



STA 

[_ML_RES+3] 

# 

them from zero 



LDA 

$00 

# 




SUBC 

[_ML_RES+2] 

# 




STA 

[_ML_RES+2] 

# 


########## 

Save the LS two bytes of the 4-byte result on the stack 

_ML_ 

.SAVE: 

LDA 

[_ML_RES+3] 

# 

Load ACC with LS byte of 2-byte 



PUSHA 


# 

result and push it onto the stack 



LDA 

[_ML_RES+2] 

# 

Load ACC with MS byte of 2-byte 



PUSHA 


# 

result and push it onto the stack 

########## 

Return 

to main program 


_ML_ 

.RET: 

LDA 

[_ML_RADD+1 

1 # 

Load ACC with LS byte of return 





# 

address from temp location and 



PUSHA 


# 

push it back onto the stack 



LDA 

[_ML_RADD] 

# 

Load ACC with MS byte of return 





# 

address from temp location and 



PUSHA 


# 

push it back onto the stack 



RTS 


# 

That's it, exit the subroutine 

########## 

Reserve 

temp locations 

for this subroutine 

_ML_ 

.RADD: 

2 BYTE 


# 

Reserve 2-byte temp location for 





# 

the return address 

_ML_ 

.MAND: 

2 BYTE 


# 

Reserve 2-byte temp location for 





# 

the multiplicand 

_ML_ 

.RES: 

4 BYTE 


# 

Reserve 4-byte temp location for 





# 

the result (product) 

_ML_ 

.FLAG: 

BYTE 


# 

Reserve 1-byte to use as a flag 

########## 

This is 

the end of 

the 

_MULT subroutine 

# - 

— 

— 


— 

-# 


Don’t panic! Just say “There’s nothing to fear but fear itself!” to yourself 
a few times until your heart stops pounding quite so fast. It’s true that 
this routine is a tad bigger than anything we’ve tackled thus far, but it’s 
really not all that complicated when you start delving into it. 

Retrieving and storing the return address 

First, at label _mult, we perform the ritual of popping the return address 
off the stack and storing it in a temporary 2-byte location called 
ML RADD. 
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Retrieving and storing the multiplicand 

Next, at label _ml_gman (“get multiplicand”), we pop the multiplicand 
off the stack and store it in a temporary 2-byte location called 
_ML_MAND. 

Retrieving and storing the multiplier 

When we come to label _ml_gmul (“get multiplier”), we first load the 
two MS bytes of our 4-byte result (called _ml_res) with zeros, and then 
we pop the multiplier off the stack and store it in the two LS bytes of our 
4-byte result. 

Inverting the multiplicand (if necessary) 

Next, at label _ml_iman (“invert multiplicand”), we load the accumula¬ 
tor with the MS byte of the multiplicand and we store a copy of this byte 
in a temporary location called _MS_FLAG. We then use a JNN (“jump if 
not negative”) instruction to test the MS bit of this MS byte to determine 
whether it’s a 0 or a 1. If this bit is 0, the value is already positive, so we 
immediately jump to label _ml_imul. Otherwise, if this bit is 1, the mul¬ 
tiplicand is negative, in which case we subtract it from zero so as to ob¬ 
tain its positive counterpart. 

Inverting the multiplier (if necessary) 

When we arrive at label _ML_IMUL (“invert multiplier”), we load the ac¬ 
cumulator with the MS byte of the multiplier, we XOR this with the con¬ 
tents of our flag, we use an and instruction to clear the LS seven bits to 0, 
and we store the result back into the flag. [In fact, due to the way in 
which we actually use this flag (at label _ml_sign), this and instruction 
is unnecessary, and serves primarily to remind us that we are interested 
only in the MS bit of this flag byte.] 

The reason we are interested in this bit is that it now contains the 
XOR of the sign bits from the multiplicand and the multiplier. If you cast 
your mind back to Chapter 4 and the discussions associated with Figures 
4-27 and 4-28, you will recall that a 0 or a 1 in this bit tells us whether the 
result from our multiplication should be positive or if it needs to be 
negated, respectively (we’ll come back to this point shortly). 

Once we’ve finished playing with the flag, we reload the accumula¬ 
tor with the MS byte of the multiplier and use a JNN (“jump if not 
negative”) to test the MS bit of this MS byte. If this bit is 0, the value is 
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already positive, so we immediately jump to label _ml_dumy. Otherwise, 
if this bit is 1, the multiplier is negative, in which case we subtract it from 
zero so as to obtain its positive counterpart. 

Two housekeeping tasks 

Before we plunge into the heart of the multiplication, we first need to 
perform two housekeeping tasks. The add at label _ml_dumy (“dum¬ 
my”) is a dummy instruction whose sole purpose is to ensure that the C 
(carry) flag contains a 0. This is followed by a BLDX instruction, which 
we use to load the index register with n^^Q [the number of times we really 
wish to go around this loop (Ibjo) plus an extra cycle to ensure that the 
result is correctly aligned]. 

The main multiplication loop 

The main multiplication loop commences at label _ML_D0IT. First we 
use a JNC (“jump if not carry”) instruction to test the value in the C (car¬ 
ry) flag. If the carry flag contains 0 (which it will do the first time round 
the loop due to our dummy ADD instruction at label _ml_dumy), we im¬ 
mediately jump to label _ML_ROT (“rotate”). Alternatively, if the carry 
flag contains a 1 (which it may well do in future iterations around the 
loop) we add a copy of our 2-byte multiplicand into the two MS bytes of 
the result. 

When we come to rotate the 4-byte result one bit to the right, we 
discover the true power of the RORC (“rotate right through the carry 
flag”) instruction that we introduced in Chapter 3. Consider the actions 
depicted in Figure L4-26. 

The values shown in Figure L4-26(a) reflect the initial conditions 
seen the very first time we go around the loop. Result bytes _ml_res+0 
and _ML_RES+1 contain Os, wheras result bytes _ml_res+2 and 
_ML_RES+2 contain a copy of the multiplier. [As we’ve already per¬ 
formed any necessary negations, we know that the MS bit of the multi¬ 
plier will be 0 indicating a positive value; meanwhile, the question mark 
(“?”) characters associated with the remaining multiplier bits indicate 
that they may be Os or Is.] 

We commence by loading the MS byte of the result from memory 
location _ml_res+0 into the accumulator. We then use an RORC to shift 
the contents of the accumulator one bit to the right; the original contents 
of the carry flag are copied into the MS bit of the accumulator and, at the 
same time, the LS bit that “falls off the end” of the accumulator is loaded 
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32-bit {4-byte) result 
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Figure L4-26. Rotating the 4-byte result one bit to the right. 


back into the carry flag [Figure L4-26(b)]. We then save the contents of 
the accumulator back into memory location _ML_RES+0. 

Next, we load the contents of memory location _ML_RES-i-l into 
the accumulator and use a new RORC to shift this value one bit to the 
right. The original contents of the carry flag (which used to be the 
LS bit from _ML_RES-i-0) are copied into the MS bit of the accumula¬ 
tor and, at the same time, the LS bit that “falls off the end” of the ac¬ 
cumulator is loaded into the carry flag [Figure L4-26(c)]. The contents 
of the accumulator are then saved back into memory location 
_ML_RES-l-l. 

And so it goes for the remaining two result bytes [Figures L4-26(d) 
and L4-26(e)]. After performing all four RORC instructions, the entire 
4-byte result has been shifted one bit to the right [Figure L4-26(f)], 
whereas the LS bit that “fell off the end” of the multiplier ends up in the 
carry flag. 

Once we’ve performed the rotate, we decrement the index register 
at label _ML_ELUP (“end of loop?”). As long as the value in the index 
register is greater than 0, the JNZ (“jump if not zero”) instruction will 
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jump back to the beginning of the loop at _ML_DOiT. Of course, the 
path we take through the loop this time depends on the contents of the 
carry flag (the bit that “fell off the end” of the multiplier). 

Checking the size of the result 

When the index register is finally decremented to zero, the JNZ instruc¬ 
tion fails, and the program arrives at the _ML_CHK label. This is where we 
test the result from the multiplication to ensure that it is less than or 
equal to +32,767. 

As shown in Figure L4-27, this means that _ML_RES+0, 
_ML_RES+0, and the MS bit of _ML_RES+0 must be 0; the remaining 
bits can be anything from $0000 to $7FFF (which equates to 0 through 
+32,767 in decimal). If any of these conditions fail, we end up at label 
_ML_ERR, at which time we load the index register with the start address 
of the appropriate error message; then we call subroutine DISPERR to 
display the message and terminate the program. 

Correcting the sign of the result 

Assuming the result is not too large, we find ourselves at label 
_ML_SIGN. This is where we test the contents of our flag to see 
whether its MS bit (which is an XOR of the signs of the original multi¬ 
plicand and multiplier) is a 0 or a 1. If it’s a I, this means that we have 
to negate the two LS bytes of the result by subtracting them from 0 
(remember that, by this point, we’ve conceptually “discarded” the two 
MS bytes). 

Saving the result and exiting the subroutine 

All that remains now is to push the two LS bytes of the result onto the 
stack at label _ml_save, to push the return address back onto the stack 
at label _ML_RET, and to then execute an RTS (“return from subrou¬ 
tine”) instruction to return us to the main body of the program. 


32-bit (4-byte) result 

/ \ 

ML RES+0 ML RES+1 ML RES+2 ML RES+3 
































0 

0 

0 

0 

0 

0 

0 

£j 

0 

0 

0 

0 

0 

0 

0 

£j 

0 

7 

7 

7 

7 

7 

7 

ZJ 

7 

7 

7 

7 

7 

7 

7 

2 } 


Figure L4-27. Checking that the result is not too large. 
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Creating and Debugging the 
_MULT Routine 

Invoke the assembler, enter the _mult subroutine as shown above, and 
save it in a file called int-mult-2-byte.asm. 

As for our previous subroutines, in order to perform preliminary 
testing on this routine, we need a . ORG statement to kick everything off, a 
. END statement to terminate things, and two labels (msg_005 and DIS- 
perr) to satisfy the external references made by the _mult routine. Thus, 
we need to “wrap” our routine with a couple of statements as follows: 



.ORG $4000 

{The _MULT 

subroutine goes here} 

MSG_005: 

• BYTE 

DISPERR: 

RTS 


.END 


Now, try clicking the assemble button and track down and debug any er¬ 
rors until you receive a “Your file was assembled without any errors” 
message. Once you reach this point, strip out the “wrapping statements” 
we added above and use the assembler’s File > Save command to save 
this file one last time. 


Modifying the Testbench to Caii the 
_MULT Routine 

Use the assembler’s File > Open command to open up the skeleton- 
lab4.asm file you created in Lab 4a, and then use the File > Save As com¬ 
mand to save this as lab4fasm. 

Modify the body of the testbench program to call the _mult rou¬ 
tine as follows (the change is highlighted in gray): 


MAINLOOP: 

JSR 

[GETNUM] 

# 

Get 1st 16-bit 

number 

(NUMA) 


JSR 

[GETNUM] 

# 

Get 2nd 16-bit 

number 

(NUMB) 


JSR 

[_MULT] 

# 

Multiply NUMB ; 

and NUMA 

together 


JSR 

[DISPNUM] 

# 

Display 16-bit 

number 

from stack 


Now, scroll down the file until the end of the subroutines to find the 
comment line that reads as follows: 




348 


LABS FOR CHAPTER 4 INTEGER ARITHMETIC 


########## This is where the math subroutine will go 

Delete this comment and leave your cursor at the beginning of this line, 
then use the assembler’s Insert > Insert File command, locate the int- 
mult-2-byte.asm source file you just created in the ensuing dialog, and 
click the Open button to insert the contents of that file into this version 
of the testbench program. 

Use the File > Save command to save this modified version of the 
testbench, and then click the assemble button to assemble it. 

Using the Testbench to Test the Routine 

Click the On/Off button on the front panel to power-up the calculator, 
use the Memory > Load RAM command to load your lab4fram file into 
the calculator’s memory, and click the Run button to set the program 
running. 

As usual, once the display has been cleared, the program will loop 
around, waiting for you to input your first number. As a first test, click 
on the following sequence of keys: 

“0,” “0,” “0,” “8,” “Enter” “0,” “0,” “0,” “8,” “Enter” 

Now, 8 io X 8 io = 64io, whereas the equivalent in hexadecimal is 815 X 8 ^^ 
= 40jg. Thus, our program should multiply these two numbers and pre¬ 
sent the following characters on the calculator’s main display: 

0008 0008 = 0040 

The program now waits for you to click any key, at which point it will 
clear the main display and wait for you to enter another two numbers. 
Experiment with different values to make sure that this routine works as 
expected. Some suggestions are as follows (these are shown in decimal; 
we’ll leave it to you to generate the hexadecimal equivalents): 

0x0 

0 X 1 

1 X 0 

1 X 1 


1 x-1 
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-1 X 1 
-1 x-l 

32,767 X 1 

32,767 X -1 

32,767 X 2 

The last example should, of course, cause the program to issue an error 
message because the result will be larger than the maximum positive 
signed integer value we can store in a 2-byte field. 

But don’t restrict yourself only to the suggestions above, which are 
primarily intended to test worst-case conditions. Just for giggles and 
grins, try multiplying a few “interesting” numbers together like 57io X 
42io, where the former value reflects the last two digits of the year Max 
(the handsome one of the authors^ was born, and the latter is the an¬ 
swer to “Life, the Universe, and Everything” according to The Hitchhik¬ 
er’s Guide to the Galaxy by Douglas Adams. 


'By some strange quirk of fate, Max is also the one who is penning these words, whereas 
Alvin is slaving away at his house on the software. 




ni nnnni ni ni i ni ni nni nni nni nnni i ni i nnnnn iiHiiiiiiMiM i nnni i nni nc 

Creating a 16-b1t 
DIVIDE Subroutine 


Objective: To create a general-purpose subroutine that can divide 

one 2-byte (16-bit) signed binary number by another and 
return a 2-byte result. 

Duration: Approximately 60 minutes. 


Another Little Thought Experiment 

As we shall come to see, the way in which we actually perform binary 
division inside a computer is somewhat tricky to wrap our brains 
around. It’s easy to lose the “thread” here, so let’s take things one step 
at a time. Toward the end of Chapter 4 we showed a simple binary di¬ 
vision example, in which we divided III 2 by IO 2 to give II 2 with a re¬ 
mainder of 1 (that is, dividing 7 10 by to give 3 10 with a remainder 
of 1 in decimal). The way in which we illustrated this operation is 
shown in Figure L4-28. 

Actually, this is something of a simplification compared to the way 
in which the computer would carry out the task. In order to see why this 
should be so, consider the way in which we originally described the first 
portion of the process in Chapter 4: 

In the case of this particular example, we know that we can’t 
divide IO 2 into O 2 , so we set the first digit in our quotient (re¬ 
sult) to 0. Similarly, we know that we can’t divide IO 2 into OI 2 , 
so we set the second digit in the quotient to 0. However, we 
can divide IO 2 into 01 12 , so we set the third digit in our quo¬ 
tient to 1. 

It all sounds so simple when you say it quickly. For example, when we 
proclaim things like “we know that we can’t divide IO 2 into OI 2 ,” how do 
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0 0 1 I 2 -► Result = 11 2 (remainder 1) 

1 02 ) 0 1 1 12 
- 10 

112-102=012-► = 01 

T 

Drop the 1 to form II 2 -► 0 1 1 

- 1 0 

112-102 = 012 -► = 01 - 

Figure L4-28. Simplified version of performing a long division in binary. 


we actually know this? In reality, without even thinking about it we sim¬ 
ply looked at the numbers and said to ourselves “IO 2 is bigger than OI 2 , 
so we can’t divide the former into the latter.” But the computer can’t do 
things this way; instead, it has to slog through the calculation one painful 
step at a time. 

As usual, the best way to visualize what’s actually happening is by 
means of a simple thought experiment. Let’s once again assume we are 
working with a really simple computer from the days of yore that is 
based on a 4-bit data bus and 4-bit memory locations. As we previously 
discussed, if we are playing with signed binary numbers, then a 4-bit field 
(known as a nybble) can be used to represent sixteen values in the range 
-8 through +7 (Figure L4-29). 

Now, let’s assume that we wish to perform the division operation 
7/2 = 3 remainder 1; as usual, we are going to employ a few cunning 
tricks (we can only imagine your surprise). 

A few cunning tricks 

We start off by reserving a 4-bit nybble for our divisor, and two 4-bit 
nybbles in which to store the result from the division (one nybble for the 
quotient and one for the remainder). If the dividend is negative, we must 
convert this value into its positive counterpart, and similarly for the divi¬ 
sor. Now let’s assume that we initialize the most-significant (MS) result 
nybble with Os and that we initialize the least-significant (LS) result nyb¬ 
ble with a copy of the dividend (already converted into a positive value if 
necessary), as shown in Figure L4-30(a). 

The first thing we do is to shift the entire 8-bit result one bit to the 
left [Figure L4-30(b)]. Note that we are not concerned with the contents 
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Figure L4-29. Signed binary values in a 4-bit field. 


of the carry flag following this operation. Also observe that performing 
this shift operation automatically causes a 0 to be loaded into the least- 
significant (LS) bit of the LS nybble. 

Next, we subtract a copy of the divisor from the most-significant 
(MS) nybble of the result as shown in Figure L4-30(c) (OOOO 2 - OOIO 2 
= IIIO 2 ). Now, this is a tricky bit. Although we know that we are actu¬ 
ally working with signed binary values, for the purposes of this portion 
of the algorithm we can “pretend” that they are unsigned quantities. In 
this case, a 0 in the carry flag (which is acting as a borrow flag in the 
case of a subtraction) indicates that we just subtracted a larger value 
from a smaller value. We know that we didn’t really wish to do this, so 
we need to recover from our rash action by adding the divisor back 
into the MS nybble of the result as shown in Figure L4-30(d) (IIIO 2 + 
OOIO 2 = OOOO 2 ). 
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Carry 8-bit field in which to store the 
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All Os - 


result (quotient and remainder) 
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(a) Initial conditions at start of first cycle 
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(b) Shift entire 8-bit result 1 bit to the left 
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(c) Subtract divisor from MS nybble of result (d) Add divisor back into MS nybble of result 
Figure L4-30. First cycle of 4-bit division test case. 


In particular, observe the 0 in the LS bit of the LS nybble of the re¬ 
sult as highlighted in Figure L4-30(d). This 0, which arrived from our 
shift operation in Figure L4-30(b), will form the first bit in our quotient. 


The fact that we discover that we didn’t really wish to perform the subtraction and end up having to 
add the divisor back into the result means that this is what is known as a restoring division algorithm. An alter¬ 
native would be a nonrestoring division algorithm, in which we would first compare the value in the divisor 
with the value in the MS portion of the result to see whether or not we wish to perform the subtraction. 


Now, let’s consider the second cycle in our 4-bit division. The ini¬ 
tial conditions for this cycle [Figure L4-31(a)] are, of course, the final 
conditions from the previous cycle [Figure L4-30(d)]. As before, the first 
thing we do is to shift the entire 8-bit result one bit to the left [Figure 
L4-31(b)]. 

Next, we subtract the divisor from the MS nybble of the result as 
shown in Figure L4-31(c) (00012-00102 = IIII 2 ). Once again, a 0 in the 
carry (borrow) flag indicates that we have attempted to subtract a larger 
value from a smaller one, so we have to undo our actions by adding the 
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(a) Initial conditions at start of second cycle (b) Shift entire 8-bit result 1 bit to the left 
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(c) Subtract divisor from MS nybble of result (d) Add divisor back Into MS nybble of result 
Figure L4-31. Second cycle of 4-bit division test case. 


divisor back into the MS nybble of the result as shown in Figure L4- 
31(d) (11112 + 00102 = 00012 ). 

As before, observe the 0 in the LS bit of the LS nybble of the result 
as highlighted in Figure L4-31(d). This 0, which was inserted by our shift 
operation in Figure L4-31(b), will form the second bit in our quotient. 

Things start to become a tad more interesting when we come to 
consider the third cycle in our 4-bit test case. After we’ve performed the 
shift operation as illustrated in Figure L4-32(b), we subtract the divisor 
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(a) Initial conditions at start of third cycle 
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(c) Subtract divisor from MS nybble of result (d) Force LS bit of LS result nybble to 1 


Figure L4-32. Third cycle of 4-bit division test case. 
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from the MS nybble of the result as shown in Figure L4-32(c) (001 12 - 

00102 = 00012). 

Following this subtraction, the carry (borrow) flag contains a 1, 
thereby indicating that the value we subtracted (the divisor) was less than 
or equal to the value in the MS nybble of the result. In this case, we keep 
the result from the subtraction as-is and we force the LS bit of the LS re¬ 
sult nybble to 1, as shown in Figure L4-32(d) (this will form the third bit 
in our quotient). 

Similarly, in the case of our fourth and final cycle in our 4-bit test 
case, once we’ve performed the shift [Figure L4-33(b)], we again subtract 
the divisor from the MS nybble of the result as shown in Figure L4-33(c) 

(00112-00102 = 00012). 

Once again, the carry (borrow) flag contains a 1 following this sub¬ 
traction, thereby indicating that the value we subtracted (the divisor) was 
less than or equal to the value in the MS nybble of the result. Thus, we 
again keep the result from the subtraction as is and we force the LS bit of 
the LS result nybble to 1, as shown in Figure L4-33(d) (this will form the 
fourth bit in our quotient). 

Now let’s remind ourselves as to what we were hoping to achieve. 
The operation we intended to perform was to divide 011 12 by OOIO 2 to 
give 001 12 with a remainder of 1 (that is, divided by 2^^ = 3^0 with a 
remainder of 1 in decimal). Good grief! If we look at Figure L4-33(d) in 
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(c) Subtract divisor from MS nybble of result (d) Force LS bit of LS result nybble to 1 


Figure L4-33. Fourth cycle of 4-bit division test case. 
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more detail, we realize that the LS nybble of our result now contains the 
quotient (001 12 = 3io)> whereas the MS nybble contains the remainder 
(OOOI 2 = lio)- It’s just like magic! 

Try it for yourself 

Before we proceed, you might wish to try working through a couple of 
simple test cases as paper exercises just to make sure you have the con¬ 
cepts firmly tied down. 

The example we worked through above involved performing the 
operation OIII 2 /OOIO 2 = 001 12 remainder 1 (that is, dividing 7^0 by 2jo to 
give 3 10 with a remainder of 1 in decimal). Why don’t you start off by per¬ 
forming the corresponding operation 01112/OOII2 = 00102 remainder 1 
(that is, dividing 7iq by 3io to give 2^0 with a remainder of 1 in decimal)? 

As a further example, you might try performing the operation 
OIOI 2 /OOII 2 = OOOI 2 remainder IO 2 (that is, dividing 5^0 by 3io to give Ijo 
with a remainder of 2^0 in decimal). The reason this later example is of 
interest is that we are going to equip our division subroutine with a 
round-half-even rounding algorithm as discussed in Chapter 4. In this 
case, we would expect the final result from our division of 5/3 = 1 re¬ 
mainder 2 to be rounded up to 2; that is, 5/3 = 2. 

Rounding 

Hold onto your hat, because this portion of our discussions may well 
make your brain go a little “wobbly” around the edges. As we noted 
above, we intend to equip our division subroutine with a round-half-even 
rounding algorithm. In our discussions in Chapter 4, we made the fol¬ 
lowing statement with regard to this form of rounding (which is also 
known as “bankers’ rounding”): 

In this case, if the digits to be discarded are greater than 0.5, 
then the integer portion of the result will be incremented by 1; 
or if the digits to be discarded are less than 0.5, the integer 
portion will be left unchanged; otherwise, if the digits to be 
discarded are equal to 0.5, the integer portion of the result will 
be rounded so as to make an even number. That is, if the inte¬ 
ger portion of the result is already even, then it will be left un¬ 
altered, but if the integer portion of the result is odd, it will be 
incremented by 1 (rounded-up) to form an even number. 
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This made sense when we were talking about rounding numbers like 
27.5, but now we have to decide what we mean by “0.5” in the context of 
an integer division. In fact, the easiest way to conceptualize this is to 
think in terms of the divisor and the remainder as follows: 

• If the remainder is greater than half of the value of the divisor, 
then we increment the result by 1. 

• If the remainder is less than half of the divisor, then we don’t do 
anything. 

• If the remainder is equal to half of the divisor, then we check the 
quotient; if the quotient is already even, we don’t do anything, 
but if it’s odd we round it up to the next even value (which sim¬ 
ply means that we add 1 to it). 

For example, consider the following operations: 

• 29/8 = 3 remainder 5. In this case, the remainder 5 is greater than 
half of the divisor (8/2 = 4), so round the quotient up to 4. 

• 27/8 = 3 remainder 3. In this case, the remainder 3 is less than 
half of the divisor (8/2 = 4), so leave the quotient as is at 3. 

• 28/8 = 3 remainder 4. In this case, the remainder 4 is exactly 
equal to half of the divisor (8/2 = 4); thus, as the original quo¬ 
tient is odd (3), round it up to the next even value (4). 

From this, we see that the key element to our rounding strategy in¬ 
volves comparing the remainder to half of the value of the divisor. In or¬ 
der to achieve this, our “knee jerk” reaction might be to simply divide 
the divisor by two and then compare it to the remainder; sadly, however, 
this can lead to errors. For example, suppose we perform the operation 
31io/9io = 3io remainder 4^0. The equivalent in binary is IIIII 2 /IOOI 2 = 
II 2 remainder IOO 2 . 

Now, we all know that as the remainder (4jo) is less than half of the 
divisor (9io)> we should leave the quotient as is. However, let’s see what 
happens if we use a “divide the divisor by two” approach. As we dis¬ 
cussed in Chapter 4, in order to divide a binary value by two, all we need 
do is to shift it one bit to the right. Thus, if we take our divisor of IOOI 2 = 
9io and shift it one bit to the right, we end up with IOO 2 = 4^0. If we now 
compare the remainder to this value, we find that they are equal, so, due 
to the fact that the original quotient was an odd value (3io)> we would 
mistakenly round it up to 4io. 
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The problem is that shifting the divisor one bit to the right caused 
the least-significant bit to “fall off the end.” If the original divisor is an 
even value, this bit will be 0, so no harm will be done. If the original divi¬ 
sor is an odd value, however, this bit will be 1, in which case we can run 
into problems, as we’ve just seen. 

Fortunately, there is a very simple solution to this conundrum. As 
opposed to dividing the divisor by two and then comparing the result to 
the remainder, we can go about things the other way around. That is, we 
can leave the divisor as is, multiply the remainder by two, and then per¬ 
form the comparison. Using this approach, we have to reformulate our 
rules as follows: 

• If two times the remainder is greater than the divisor, then we in¬ 
crement the result by 1. 

• If two times the remainder is less than the divisor, then we don’t 
do anything. 

• If two times the remainder is equal to the divisor, then we check 
the quotient; if the quotient is already even, we don’t do any¬ 
thing, but if it’s odd we round it up to the next even value. 

In order to see how this works, let’s return to our example operation, 
31io/9io = 3io remainder 4^0 (that is, IIIII 2 /IOOI 2 = II 2 remainder IOO 2 in 
binary). As we discussed in Chapter 4, in order to multiply a binary value 
by two, all we need do is to shift it one bit to the left. Thus, if we take our 
remainder of IOO 2 = 4io and shift it one bit to the left, we end up with IOOO 2 
= Sjo- If we now compare this value to the divisor, we see that the divisor is 
the greater, in which case we know to leave the existing quotient as is. 

Sign correction 

Finally, we need to perform any sign correction on the result. The rules 
for this are pretty much the same as for multiplication: 

+ divided by - 1 - equals - 1 - 

+ divided by - equals - 

- divided by + equals - 

- divided by - equals - 1 - 

As you will see in the subroutine described below, the way in which we 
test for this and perform any necessary sign corrections is the same as for 
the multiplication routine discussed in the previous lab. 
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The 16-bit DIV Subroutine Itself 


When it comes to our real _Div subroutine, of course, we intend to di¬ 
vide one 2-byte (16-bit) number by another. Following rounding, we will 
discard any remainder and leave the 2-byte quotient on the top of the 
stack. In order to provide a point of reference, the names of the main 
storage locations used in this routine are as shown in Figure L4-34. 


####################################################################### 


# Name: _DIV 

# 

# Function: Divide one 16-bit signed binary number by another and 
return a 16-bit result in the range -32,767 to +32,767 


# 

# 

# Entry: 

# 

# 

# 

# 

# 

# 

# 

# Exit: 

# 

# 

# 

# Modifies: 

# 

# Size: 

# 


Top of stack 

Most-significant byte of return address 
Least-significant byte of return address 
Most-significant byte of second number (Divisor) 
Least-significant byte of second number (Divisor) 
Most-significant byte of first number (Dividend) 
Least-significant byte of first number (Dividend) 


Top of stack 

Most-significant byte of result 
Least-significant byte of result 

Accumulator and Index Register 


(Quotient) 

(Quotient) 


Program 

Data 


298 bytes 
9 bytes 


####################################################################### 

########## Get return address from stack and store it 

_DIV: POPA # Retrieve MS byte of return 

STA [_DV_RADD+0] # address from stack and store it 

POPA # Retrieve LS byte of return 

STA [_DV_RADD+1] # address from stack and store it 

########## Get divisor from stack and store it 

_DV_GDIV: POPA # Retrieve MS byte of divisor 

STA [_DV_DIV+0] # from stack and store it 

POPA # Retrieve LS byte of divisor 

STA [_DV_DIV+1] # from stack and store it 

########## Check that we're not trying to divide by zero 

_DV_CHKZ: OR [_DV_DIV+0] # OR ACC with MS byte of divisor 

JNZ [_DV_GDND] # If non-zero, carry on ... 
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Copy of the 16-bit divisor 
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Ends up containing the remainder Ends up containing the quotient 


_DV_RES+0 _DV_RES+1 _DV_RES+2 _DV_RES+3 

Figure L4-34, Names of primary storage locations in the real subroutine. 


_DV_ERRZ: 

BLDX 

MSG_007 

# 

Load X reg with addr of message 


JSR 

[DISPERR] 

# 

Jump to display error subroutine 




# 

(which terminates the program) 

########## 

Get dividend from stack and store it 

_DV_GDND: 

LDA 

$00 

# 

Load ACC with 0 and save it to 


STA 

[_DV_RES+0] 

# 

the two MS bytes of the 


STA 

[_DV_RES+1] 

# 

4-byte result 


POPA 


# 

Retrieve MS byte of dividend 


STA 

[_DV_RES+2] 

# 

from stack and store it 


POPA 


# 

Retrieve LS byte of dividend 


STA 

[_DV_RES+3] 

# 

from stack and store it 

########## 

Invert 

divisor if necessary (store sign in flag) 

_DV_IDIV; 

LDA 

[_DV_DIV+0] 

# 

Load ACC with MS divisor 


STA 

[_DV_FLAG] 

# 

and store a copy in the flag 


JNN 

[_DV_IDND] 

# 

If positive value, jump to next test 




# 

... otherwise ... 


LDA 

$00 

# 

Load ACC with 0 


SUB 

[_DV_DIV+1] 

# 

Subtract (no carry) LS byte of 


STA 

[_DV_DIV+1] 

# 

divisor and store the result 


LDA 

$00 

# 

Load ACC with 0 


SUBC 

[_DV_DIV+0] 

# 

Subtract (with carry) MS byte of 


STA 

[_DV_DIV+0] 

# 

divisor and store the result 

########## 

Invert 

dividend if 

necessary (XOR sign in flag) 

_DV_IDND: 

LDA 

[_DV_FLAG] 

# 

Load the flag 


XOR 

[_DV_RES+2] 

# 

XOR it with MS byte of dividend 


AND 

%10000000 

# 

Clear bits (except sign) to 0 


STA 

[_DV_FLAG] 

# 

Store the flag away again 


LDA 

[_DV_RES+2] 

# 

Load ACC with MS dividend 
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JNN 

[_DV_LOOP] 

# 

If positive value, jump to next part 




# 

... otherwise ... 


LDA 

$00 

# 

Load ACC with 0 


SUB 

[_DV_RES+3] 

# 

Subtract (no carry) LS byte of 


STA 

[_DV_RES+3] 

# 

dividend and store the result 


LDA 

$00 

# 

Load ACC with 0 


SUBC 

[_DV_RES+2] 

# 

Subtract (with carry) MS byte of 


STA 

[_DV_RES+2] 

# 

dividend and store the result 

########## 

Hold 1 

tight—this is 

the 

start of the main division loop 

_DV_LOOP: 

BLDX 

16 

# 

Load index reg with the number of 




# 

times we want to go around loop 

_DV_DOIT: 

LDA 

[_DV_RES+3] 

# 

Shift the 4-byte {32-bit) result 


SHL 


# 

one bit to the left. Start with 


STA 

[_DV_RES+3] 

# 

the LS byte: _DV_RES+3 


LDA 

[_DV_RES+2] 

# 

Now do _DV_RES+2 


ROLC 


# 

Use a rotate here 


STA 

[_DV_RES+2] 

# 



LDA 

[_DV_RES+1] 

# 

Now do _DV_RES+1 


ROLC 


# 

Use a rotate here 


STA 

[_DV_RES+1] 

# 



LDA 

[_DV_RES+0] 

# 

Now do _DV_RES+0 


ROLC 


# 

Use a rotate here 


STA 

[_DV_RES+0] 

# 


########## 

Subtract the divisor from the two MS bytes of the result 

_DV_SUB: 

LDA 

[_DV_RES+1] 

# 

Load ACC with _DV_RES+1 


SUB 

[_DV_DIV+1] 

# 

Subtract (no carry) LS byte of 


STA 

[_DV_RES+1] 

# 

divisor and store result 


LDA 

[_DV_RES+0] 

# 

Load ACC with DV_RES+0 


SUBC 

[_DV_DIV+0] 

# 

Subtract (with carry) MS byte of 


STA 

[_DV_RES+0] 

# 

divisor and store result 

########## 

Check 

to see if we 

need to add the divisor back in again 

_DV_ADD; 

JC 

[_DV_SET1] 

# 

Jump if carry (borrow) = 1 


LDA 

[_DV_RES+1] 

# 

Load ACC with _DV_RES+1 


ADD 

[_DV_DIV+1] 

# 

Add (no carry) LS byte of 


STA 

[_DV_RES+1] 

# 

divisor and store result 


LDA 

[_DV_RES+0] 

# 

Load ACC with DV_RES+0 


ADDC 

[_DV_DIV+0] 

# 

Add (with carry) MS byte of 


STA 

[_DV_RES+0] 

# 

divisor and store result 


JMP 

[_DV_ELUP] 

# 

Jump to the end of the loop 

########## 

Force 

the LS bit of 

the LS result byte to 1 

_DV_SET1: 

LDA 

[_DV_RES+3] 

# 

Load LS byte of result 


OR 

%00000001 

# 

Force LS bit to 1 


STA 

[_DV_RES+3] 

# 

and store it back again 

########## 

Check 

to see if we' 

re done 
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_DV_ 

_ELUP: 

DECX 


# 

Decrement the index register 



JNZ 

[_DV_DOIT] 

# 

If not zero, then do another loop 

########## 

Perform 

a round-half- 

-even algorithm 

_DV_ 

_RND: 

LDA 

[_DV_RES+1] 

# 

Load LS byte of remainder 



SHL 


# 

Multiply by two (shift left one 



STA 

[_DV_RES+1] 

# 

bit and store result 



LDA 

[_DV_RES+0] 

# 

Repeat for MS byte of remainder 



ROLC 


# 

but use a rotate this time 



STA 

[_DV_RES+0] 

# 






# 

Start by comparing MS bytes 

_DV_ 

_CPMS : 

LDA 

[_DV_DIV+0] 

# 

Load ACC with MS divisor 



CMPA 

[_DV_RES+0] 

# 

Compare to MS remainder x2 



JC 

[_DV_SIGN] 

# 

Do nothing if divisor is bigger 



JNZ 

[_DV_FRND] 

# 

Force round up if divisor is smaller 





# 

If MS bytes are equal compare LS 

_DV_ 

_CPLS: 

LDA 

[_DV_DIV+1] 

# 

Load ACC with LS divisor 



CMPA 

[_DV_RES+1] 

# 

Compare to LS remainder x 2 



JC 

[_DV_SIGN] 

# 

Do nothing if divisor is bigger 



JNZ 

[_DV_FRND] 

# 

Force round up if divisor is smaller 





# 

Do round-half-even if MS&LS are equal 

_DV_ 

_RHE: 

LDA 

[_DV_RES+3] 

# 

Load LS byte of quotient 



AND 

%00000001 

# 

Mask out all but LS bit 



JZ 

[_DV_SIGN] 

# 

Do nothing if quotient already even 





# 

Otherwise do a round-up 

_DV_ 

_FRND: 

LDA 

[_DV_RES+3] 

# 

Load ACC with LS quotient 



ADD 

$01 

# 

Add 1 (no carry) to the ACC 



STA 

[_DV_RES+3] 

# 

and store the result 



LDA 

[_DV_RES+2] 

# 

Load ACC with MS quotient 



ADDC 

$00 

# 

Add 0 (but with carry flag) 



STA 

[_DV_RES+2] 

# 

and store the result 

########## 

Check the flag to see if we have to negate the result 

_DV_ 

.SIGN: 

LDA 

[_DV_FLAG] 

# 

Load the flag byte 



JNN 

[_DV_SAVE] 

# 

Jump if MS bit = 0 



LDA 

$00 

# 

Otherwise invert LS two bytes 



SUB 

[_DV_RES+3] 

# 

of the result by subtracting 



STA 

[_DV_RES+3] 

# 

them from zero 



LDA 

$00 

# 




SUBC 

[_DV_RES+2] 

# 




STA 

[_DV_RES+2] 

# 


########## 

Save the 

LS two bytes of the 4-byte result on the stack 

_DV_ 

.SAVE: 

LDA 

[_DV_RES+3] 

# 

Load ACC with LS byte of 2-byte 



PUSHA 


# 

quotient and push it onto the stack 
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LDA 

[_DV_RES+2] 

# 

Load ACC with MS byte of 2-byte 


PUSHA 


# 

quotient and push it onto the stack 

########## 

Return 

to main program 


_DV_RET: 

LDA 

[_DV_RADD+1 

1 # 

Load ACC with LS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


LDA 

[_DV_RADD] 

# 

Load ACC with MS byte of return 




# 

address from temp location and 


PUSHA 


# 

push it back onto the stack 


RTS 


# 

That's it, exit the subroutine 

########## 

Reserve 

temp locations 

for this subroutine 

_DV_RADD: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the return address 

_DV_DIV: 

.2BYTE 


# 

Reserve 2-byte temp location for 




# 

the divisor 

_DV_RES; 

. 4BYTE 


# 

Reserve 4-byte temp location for 




# 

the result (remainder + quotient) 

_DV_FLAG: 

.BYTE 


# 

Reserve 1-byte to use as a flag 

########## 

This is 

the end of 

the 

_DIV subroutine 

# - 

-- 


— 

- # 


Wow! This is even bigger than the multiply routine from the previ¬ 
ous lab. But, as usual, it’s really not all that scary when you start delving 
into it. 

Retrieving and storing the return address 

First, at label _DIV, we perform the standard task of popping the return 
address off the stack and storing it in a temporary 2-byte location called 
_DV_RADD. 

Retrieving and storing the divisor 

Next, at label _dv_GDIV (“get divisor”), we pop the divisor off the stack 
and store it in a temporary 2-byte location called _dv_div. 

Testing fora "divide by zero" 

Following the previous operation, the accumulator already contains a 
copy of the LS byte of the divisor. Thus, when we come to label 
_DV_CHKZ (“check for zero”), all we have to do is OR in a copy of the 
MS byte of the divisor. If the accumulator still contains zero following 
this operation, then we know we have a problem, in which case we will 
display the appropriate error message and terminate the program. 
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Retrieving and storing the dividend 

When we come to label _dv_GDND (“get dividend”), we first load the 
two MS bytes of our 4-byte result (called _dv_res) with zeros, and then 
we pop the dividend off the stack and store it in the two LS bytes of our 
4-byte result. 

Inverting the divisor (if necessary) 

Next, at label _dv_idiv (“invert divisor”), we load the accumulator with 
the MS byte of the divisor and we store a copy of this byte in a temporary 
location called _dv_flag. We then use a JNN (“jump if not negative”) in¬ 
struction to test the MS bit of this MS byte to determine whether it’s 0 or a 
1. If this bit is 0, the value is already positive, so we immediately jump to 
label _DV_IDND. Otherwise, if this bit is 1, the divisor is negative, in which 
case we subtract it from zero so as to obtain its positive counterpart. 

Inverting the dividend (if necessary) 

When we arrive at label _DV_IDND (“invert dividend”), we load the ac¬ 
cumulator with the MS byte of the dividend, we XOR this with the con¬ 
tents of our flag, we use an and instruction to clear the LS seven bits to 0, 
and we store the result back into the flag. 

As before, the reason we are interested in this bit is that it now con¬ 
tains the XOR of the sign bits from the divisor and the dividend. A 0 or a 
1 in this bit tells us whether the result from our division should be posi¬ 
tive or if it will need to be negated, respectively (we’ll return to this point 
in a little while). 

Once we’ve finished playing with the flag, we reload the accumula¬ 
tor with the MS byte of the dividend and use a JNN (“jump if not nega¬ 
tive”) to test the MS bit of this MS byte. If this bit is 0, the value is al¬ 
ready positive, so we immediately jump to label _dv_loop. Otherwise, if 
this bit is 1, the dividend is negative, in which case we subtract it from 
zero so as to obtain its positive counterpart. 

The main division loop 

Just before we commence the main division loop, we use a bldx (“big 
load index register”) instruction to load the index register with 16io, 
which is the number of times we wish to go around the loop. 

The main division loop itself commences at label _dv_doit. Our 
first task is to shift the 4-byte result field one bit to the left. This is where 
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we take advantage of the rolc (“rotate left through the carry flag”) in¬ 
struction that we introduced in Chapter 3. Consider the actions depicted 
in Figure L4-35. 

The values shown in Figure L4-35(a) reflect the initial conditions 
seen the very first time we go around the loop. Result bytes _dv_res+0 
and _DV_RES+1 contain Os, whereas result bytes _dv_RES+2 and 
_DV_RES+3 contain a copy of the dividend. [As we’ve already performed 
any necessary negations, we know that the MS bit of the dividend will be 
0 indicating a positive value; meanwhile, the question mark (“?”) charac¬ 
ters associated with the remaining dividend bits indicate that they may 
be Os or Is.] 

We commence by loading the LS byte of the result from memory 
location _DV_RES+3 into the accumulator. We then use a SHE (“shift 
left”) instruction to shift the contents of the accumulator one bit to 


32-bit (4-byte) result 


DV RES+0 DV RES+1 DV RES+2 DV RES+3 


0|o|o|o|o|o|o|o] 0 0 0 0 0 0 ^ |o|?|?|?|?|?|?p^ |?|?|?|?|?|?|^ (a) start 

(b) Shift byte 3 
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(c) Rotate byte 2 


(d) Rotate byte 1 


(e) Rotate byte 0 


0 |o|o|o|o|o|oj^ |o|o|o|o|o|o|o|o] |?|?|?|?|?|?|?j^ |?|?|?|?|?|?|^ (f) End 


Figure L4-35. Shifting the 4-byte result one bit to the left. 
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the left [Figure L4-35(b)]. As part of this shift operation, a 0 is auto¬ 
matically loaded into the LS bit and, at the same time, the MS bit 
that “falls off the end” of the accumulator is loaded into the carry flag. 
(The “X” character associated with the original value in the carry flag 
is used to indicate that we don’t have any interest in this value.) We 
then save the contents of the accumulator back into memory location 
_DL_RES+3. 

Next, we load the contents of memory location _dl_res+2 into 
the accumulator and use a rolc to shift this value one bit to the left [Fig¬ 
ure L4-35(c)]. The original contents of the carry flag (which used to be 
the MS bit from _DV_RES+3) are copied into the LS bit of the accumula¬ 
tor, and, at the same time, the MS bit that “falls off the end” of the accu¬ 
mulator is loaded into the carry flag. The contents of the accumulator are 
then saved back into memory location _dv_RES+2. 

And so it goes for the remaining two result bytes [Figures L4-35(d) 
and L4-35(e)]. The combination of the she instruction and the three 
ROLC instructions means that the entire 4-byte result ends up shifted 
one bit to the left with a 0 inserted into the LS bit of the LS byte [Figure 
L4-35(f)]. 

Once we’ve performed this shift, we subtract the divisor from the 
MS two bytes of the result at label _dv_SUB. Next, at label _dv_add, 
we check the state of the carry flag. If the carry flag is 0, we know that 
we’ve tried to subtract a larger value from a smaller one, in which 
case we add the divisor back into the MS two bytes of the result and 
then jump to the end of the loop. Otherwise, we jump to label 
_DV_SETl, at which point we load the LS bit of the LS byte of the 
result with a 1. 

When we eventually arrive at label dv_elup (“end of loop”) we 
decrement the index register. So long as the index register still contains a 
nonzero value, we jump back to the beginning of the loop to perform 
another cycle. 

Performing a round-half-even 

When the index register is finally decremented to zero, the JNZ instruc¬ 
tion fails, and the program arrives at the _DV_RND (“round”) label. We 
start by multiplying the remainder by two, which involves shifting the 
MS two bytes of the result (the two bytes containing the remainder) one 
bit to the left. 
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Next, at label _dv_CPMS (“compare MS bytes”), we load the accu¬ 
mulator with the MS byte of the divisor. We then use a cmpa (“compare 
accumulator”) instruction to compare this value with the MS byte of the 
remainder (which we just multiplied by two). We now have three possi¬ 
bilities: 

a) The contents of the accumulator (the MS byte of the divisor) are the 
larger. This will be indicated by the fact that the carry flag contains 1 
(and the zero flag contains 0). In this case, we don’t have to do any¬ 
thing and can jump immediately to label _DV_SIGN. 

b) The contents of the accumulator are the smaller. This will be indicat¬ 
ed by the fact that both the carry and zero flags contain 0. In this case, 
we definitely wish to force a round operation (add 1 to the quotient) 
by jumping to label _DV_FR]X[D (“force a round”). 

c) The two values are equal. This will be indicated by the fact that the 
zero flag contains 1 (and the carry flag contains 0). In this case, we 
drop through to label _DV_CPLS (“compare LS bytes”) as discussed 
below. 

If we arrive at label _dv_CPLS, we know that the MS bytes of the 
divisor and the remainder (multiplied by two) are equal. This means that 
we now have to compare their LS bytes, so we load the accumulator with 
the LS byte of the divisor and use a new cmpa instruction to compare 
this value with the LS byte of the remainder. As before, there are three 
possibilities: 

d) The contents of the accumulator (the LS byte of the divisor) are the 
larger. In this case, we don’t have to do anything and can jump imme¬ 
diately to label _DV_SIGN. 

e) The contents of the accumulator are the smaller. In this case, we defi¬ 
nitely wish to force a round operation (add 1 to the quotient) by 
jumping to label _DV_FRND (“force a round”). 

f) The two values are equal. This is the only case in which we may need 
to perform the round-half-even operation. We start by loading the LS 
byte of the quotient and masking out all but the LS bit. If this bit is a 
zero, the quotient is already an even number, in which case we don’t 
have to do anything and can jump immediately to label _DV_SIGN. 
Otherwise, the quotient is an odd number, so we fall through to label 
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_DV_FRND, at which point we force a round operation (that is, we 
add 1 to the quotient). 

Correcting the sign of the result 

Following the round operation, we find ourselves at label _DV_SIGN. 
This is where we test the contents of our flag to see whether its MS bit 
(which is an XOR of the signs of the original divisor and dividend) is a 0 
or a 1. If it’s a 1, this means that we have to negate the quotient (the two 
LS bytes of the result) by subtracting them from 0. 

Saving the result and exiting the subroutine 

All that remains now is to push the quotient onto the stack at label 
_DV_SAVE, push the return address back onto the stack at label 
_DV_RET, and execute an RTS (“return from subroutine”) instruction 
to return us to the main body of the program. 

Creating and Debugging 
the _DIV Routine 

Invoke the assembler, enter the _Div subroutine as shown above, and 
save it in a file called int-div-2-hyte.asm. 

As usual, in order to perform preliminary testing on this routine, 
we need a . ORG statement to kick everything off, a . end statement to 
terminate things, and two labels (msg_007 and disperr) to satisfy the 
external references made by the _Div routine. Thus, we need to “wrap” 
our routine with a couple of statements as follows: 



.ORG $4000 

{The _DIV 

subroutine goes here} 

MSG_007: 

.BYTE 

DISPERR: 

RTS 


.END 


Now, try clicking the assemble button and track down and debug 
any errors until you receive a “Your file was assembled without any er¬ 
rors” message. Once you reach this point, strip out the “wrapping state¬ 
ments” we added above and use the assembler’s File > Save command to 
save this file one last time. 
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Modifying the Testbench to Caii the 
_DiV Routine 

Use the assembler’s File > Open command to open up the skeleton- 
lab4.asm file you created in Lab 4a, and then use the File > Save As com¬ 
mand to save this as lab4g.asm. 

Modify the body of the testbench program to call the _Div routine 
as follows (the change is highlighted in gray): 

MAINLOOP: JSR [GETNUM] # Get 1st 16-bit number (NOMA) 

JSR [GETNUM] # Get 2nd 16-bit number (NUMB) 

JSR [_DIV] # Divide NUMA by NUMB 

JSR [DISPNUM] # Display 16-bit number from stack 

Now, scroll down the file until the end of the subroutines to find the 
comment line that reads as follows: 

########## This is where the math subroutine will go 

Delete this comment and leave your cursor at the beginning of this line, 
then use the assembler’s Insert > Insert File command, locate the int- 
div-2-byte.asm source file you just created in the ensuing dialog, and 
click the Open button to insert the contents of that file into this version 
of the testbench program. 

Use the File > Save command to save this modified version of the 
testbench, and then click the assemble button to assemble it. 

Using the Testbench to Test the Routine 

Click the On/Off button on the front panel to power-up the calculator, 
use the Memory > Load RAM command to load your lab4g.ram file into 
the calculator’s memory, and click the Run button to set the program 
running. 

As usual, once the display has been cleared, the program will loop 
around, waiting for you to input your first number. As a first test, click 
on the following sequence of keys: 

“0,” “0,” “0,” “7,” “Enter” “0,” “0,” “0,” “3,” “Enter” 

Now 7io divided by 3io = 2io> remainder 1. As this remainder is less than 
half of the divisor, the result will not be rounded, so our program should 
present the following characters on the calculator’s main display: 
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0007 0003 = 0002 

The program now waits for you to click any key, at which point it will 
clear the main display and wait for you to enter another two numbers. 
Now try clicking the following sequence of keys: 

“0,” “0,” “0,” “7,” “Enter” “0,” “0,” “0,” “2,” “Enter” 

In this case, 7^0 divided by = 3io> remainder 1. However, as this re¬ 
mainder is equal to half of the divisor, and as the original quotient is odd 
and we’re using a round-half-even algorithm, the result will be rounded. 
Thus, our program should present the following characters on the calcu¬ 
lator’s main display: 

0007 0002 = 0004 

Experiment with different values to make sure that this routine 
works as expected. Some suggestions are as follows (these are shown in 
decimal; we’ll leave it to you to generate the hexadecimal equivalents): 

1/1 

1/-1 

- 1/1 

- 1/-1 

32,767/1 

32,767/-l 

32,767/2 

1/0 

The last example should, of course, cause the program to issue an error 
message and terminate itself, because the result of dividing anything by 
zero is undefined in this implementation of our calculator. 

As usual, don’t restrict yourself only to the suggestions above, 
which are primarily intended to test worst-case conditions. Just for gig¬ 
gles and grins, try dividing a few “interesting” numbers like 1984io/42io 
to ensure that everything functions as planned. 
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Creating the 
Calculator Framework 


Objective: To create a “framework” program that can be used as the 

basis to implement an extensible calculator. 

Duration: Approximately 40 minutes. 

Creating the Framework Program 

After the complexities of the previous labs, you may be a tad worried that 
creating a full-fledged calculator program is going to be mind-bogglingly 
complex. But there’s no need to fret because we’ve already set the scene 
and done most of the drudgework in our earlier experiments. All we 
really have to do at this stage is to gather our existing functions and add a 
bit of “glue code” to stick everything together. 

Our first task—the purpose of this lab—is to create a framework 
program that we can use as the basis to implement a very simple four- 
function calculator. Furthermore, we want to create this framework in 
such a way that we can easily add enhanced capabilities and additional 
functions in the future. 

Building a skeleton framework 

Just to make sure that we’re all marching to the same drumbeat, we are 
going to construct our framework program from the ground up. As a 
starting point, let’s invoke the assembler and enter the following com¬ 
ments and directive statements: 

####################################################################### 
## Start of constant declarations ## 

####################################################################### 

## Constant declarations will go here 
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####################################################################### 
## End of constant declarations ## 

####################################################################### 

■ORG $4000 # Set program origin 

####################################################################### 
## Start of initialization ## 

####################################################################### 

## Initialization statements will go here 

####################################################################### 
## End of initialization ## 

####################################################################### 

####################################################################### 
## Start of main program body ## 

####################################################################### 

## Main body will go here 

####################################################################### 
## End of main program body ## 

####################################################################### 

####################################################################### 
## Start of subroutines ## 

####################################################################### 

## Subroutines will go here 

####################################################################### 
## End of subroutines ## 

####################################################################### 

####################################################################### 
## Start of global data ## 

####################################################################### 

## Global data will go here 

####################################################################### 
## End of global data ## 

####################################################################### 

.END # That'S all folks 

Use the assembler’s File > Save As command to save this skeleton 
framework as LabSa.asm (as always, you should never fail to take an op¬ 
portunity to save your work). Next, use the assembler’s File > Assemble 
command to make sure that everything is as it should be (the sooner we 
detect any errors, the easier they are to identify and rectify). 
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Adding constant declarations 

Scroll your way to the “Constant Declarations” portion of the skeleton; 
delete the comment that says “## Constant declarations will go here,” 
and replace it with the following statements: 


MAINDISP: 

■ EQU 

$F031 

# 

Address of out port 

for main display 

SIXLEDS: 

■ EQU 

$F032 

# 

Address of out port 

;or six LEDs 

KEYPAD: 

■ EQU 

$F011 

# 

Address of input port for keypad 

CLRCODE: 

■ EQU 

$10 

# 

Special code to clear main display 

BELLCODE: 

■ EQU 

$11 

# 

Special code to "beep" the display 

BACKCODE: 

■ EQU 

$12 

# 

Code to delete last 

character 

BINMODE: 

■ EQU 

%00000100 

# 

LED code to indicate 

binary mode 

DECMODE: 

■ EQU 

%00000010 

# 

LED code to indicate 

decimal mode 

HEXMODE: 

■ EQU 

%00000001 

# 

LED code to indicate 

hexadecimal mode 

CLRKEY: 

■ EQU 

$10 

# 

Code associated with 

the "Clear" key 

CEKEY: 

■ EQU 

$11 

# 

Code associated with 

the "CE" key 

BACKKEY: 

■ EQU 

$12 

# 

Code associated with 

the "Back" key 

ENTERKEY: 

■ EQU 

$13 

# 

Code associated with 

the "Enter" key 


As with our previous programs, the first block of these statements is 
used to associate labels with the calculator’s input and output ports. 

The second block defines the codes used to clear the main display, 
to cause the display to emit an annoying “beep”, and to delete the last 
character to have been displayed. 

The third block specifies the different binary patterns of Os and Is 
required to light the binary (“Bin”), decimal (“Dec”), and hexadecimal 
(“Hex”) lights on the main display. 

The fourth block is used to associate labels with the keypad’s four 
main “control” keys. We may or may not decide to implement the func¬ 
tions associated with all of these keys, but if we do, then the tasks they 
perform will be as follows: 

Clear: Clear the entire calculation and start again 

CE: Clear the current data entry (but keep the rest of the calculation as is) 

Back: Delete the last digit from the display (clicking this key multiple 
times should delete multiple digits) 

Enter: Indicates the end of a numerical value 

Once again, use the assembler’s File > Assemble command to save 
these changes and check that we haven’t introduced any errors (we won’t 
keep harping on about this—it’s your responsibility to stay on top of this 
sort of thing henceforth). 
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Adding the initialization statements 

Now scroll your way to the “Initialization” portion of the skeleton, delete 
the comment that says “## Initialization statements will go here,” and re¬ 
place it with the following statements: 


INIT: 

LDA 

CLRCODE 

# 

Load accumulator with clear code 


STA 

[MAINDISP] 

# 

and write it to the main display 


LDA 

DECMODE 

# 

Load accumulator with dec mode code 


STA 

[SIXLEDS] 

# 

and write it to port driving LEDs 


BLDSP 

$EFFF 

# 

load stack pointer with initial value 


Reserving placeholders for subroutines 

We don’t actually want to enter any subroutines at this moment in time, 
but we do want to reserve some placeholders for them so as to make our 
lives easier. So, scroll your way to the “Subroutines” portion of the skele¬ 
ton, delete the comment that says “## Subroutines will go here,” and re¬ 
place it with the following “stub” statements: 


GETSTUFF: 

RTS 

# 

This 

will 

be the 

raw input routine 

GETNUM: 

RTS 

# 

This 

will 

get a 

decimal number 

DISPNUM: 

RTS 

# 

This 

will 

display a decimal number 

DISPERR: 

RTS 

# 

This 

will 

display an error message 

CHK2NEG: 

RTS 

# 

This 

will 

check 

for -32,768 

_NOTYET: 

RTS 

# 

Catch-all 

for unimplemented functions 

_ADD: 

RTS 

# 

This 

will 

be our 

16-bit addition 

_SUB: 

RTS 

# 

This 

will 

be our 

16-bit subtraction 

_MULT: 

RTS 

# 

This 

will 

be our 

16-bit multiply 

_DIV: 

RTS 

# 

This 

will 

be our 

16-bit divide 

_NEG: 

RTS 

# 

This 

will 

be our 

16-bit negation 


In the context of programming, the term “stub” refers to a dummy function, procedure, or subrou- 
tine. The stub routine need not contain any code and is primarily used to prevent “undefined label” errors 
during assembly, compilation, or linking. 


Reserving global temporary data locations 
and messages 

Now we’re going to reserve some locations in which to store temporary 
data values as required. Scroll your way to the “Global Data” portion of 
the skeleton, delete the comment that says “## Global data will go here,” 
and replace it with the following statements: 







CREATING THE FRAMEWORK PROGRAM 


379 


INSTRING: . 

.BYTE 

*10 

# Reserve 

10 bytes to store a 

string 

TEMPX: 

.2BYTE 

$0000 

# Reserve 

2-byte location for 

X reg 

########## 

Start 

of message 

strings 



########## 

Start 

of cunning 

re-direction 




Next, place your cursor at the beginning of the blank line following 
the “Start of message strings” comment; then, use the assembler’s Insert 
> String command to access its associated dialog window and use this 
tool to insert the following message strings (this utility was introduced 
in Lab 2f): 


Label 

Message 

MSG_000 

ERROR: 

MSG_001 

Carry = 1 

MSG_002 

Borrow = 0 

MSG_003 

Overflow 

MSG_004 

Underflow 

MSG_005 

Too big 

MSG_006 

Too small 

MSG_007 

Divide by 0 

MSG_008 

Out of range 

MSG_009 

-32,768 

MSG_010 

Not implemented 


As we previously discussed when we did this in Lab 4a, with regard to 
message MSG_000, make sure you include a space following the colon 
(that is, the string should be “error : ”). 

Now, place your cursor at the beginning of the blank line following 
the “Start of cunning redirection” comment and insert the following 
statements (we’ll discuss what this is all about shortly): 


KEY_ 

_H14 : 

.2BYTE 

_NEG 

# 

+ /- 

Negate 

KEY_ 

_H15 : 

.2BYTE 

_NOTYET 

# 


Decimal point 

KEY_ 

_H16 : 

.2BYTE 

_ADD 

# 

+ 

Add 

KEY_ 

_H17 : 

.2BYTE 

_SUB 

# 

- 

Subtract 

KEY_ 

_H18 : 

.2BYTE 

_MULT 

# 

* 

Multiply 

KEY_ 

_H19 : 

.2BYTE 

_DIV 

#/ 


Divide 

KEY_ 

_H1A: 

.2BYTE 

_NOTYET 

# 

= 

Equals 

KEY_ 

_H1B: 

.2BYTE 

_NOTYET 

# 

( 

Left parenthesis 

KEY_ 

_H1C: 

.2BYTE 

_NOTYET 

# 

Pi 

Constant Pi 

KEY_ 

_H1D: 

.2BYTE 

_NOTYET 

# 

Mod 

Modulus 

KEY_ 

_H1E: 

.2BYTE 

_NOTYET 

# 


Unassigned 







380 


LABS FOR CHAPTER 5 CREATING AN INTEGER CALCULATOR 


KEY_ 

_H1E: 

.2BYTE 

_NOTYET 

# 

) 

Right parenthesis 

KEY_ 

_H2 0 : 

.2BYTE 

_NOTYET 

# 

F-S 

Scientific on/off 

KEY_ 

_H21: 

.2BYTE 

_NOTYET 

# 

Exp 

Exponential 

KEY_ 

_H22 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H23 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H24 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2 5 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2 6 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H27 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2 8 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2 9 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2A: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2B: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2C: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2D: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2E: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H2E: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H3 0: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H31: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H32 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H33 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H34 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H3 5: 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H3 6: 

.2BYTE 

_NOTYET 

# 

n! 

Factorial 

KEY_ 

_H37 : 

.2BYTE 

_NOTYET 

# 

Log 

logarithm 

KEY_ 

_H3 8: 

.2BYTE 

_NOTYET 

# 

Tan 

Tangent 

KEY_ 

_H3 9: 

.2BYTE 

_NOTYET 

# 

Cos 

Cosine 

KEY_ 

_H3A: 

.2BYTE 

_NOTYET 

# 

Sin 

Sine 

KEY_ 

_H3B: 

.2BYTE 

_NOTYET 

# 

1/x 

Reciprocal 

KEY_ 

_H3C: 

.2BYTE 

_NOTYET 

# 

Rx 

Square root 

KEY_ 

_H3D: 

.2BYTE 

_NOTYET 

# 

x^2 

X squared 

KEY_ 

_H3E: 

.2BYTE 

_NOTYET 

# 

x''3 

X cubed 

KEY_ 

_H3E: 

.2BYTE 

_NOTYET 

# 

y^x 

Y to the power of X 

KEY_ 

_H40 : 

.2BYTE 

_NOTYET 

# 

Hex 

Switch to hex 

KEY_ 

_H41: 

.2BYTE 

_NOTYET 

# 

Dec 

Switch to decimal 

KEY_ 

_H42 : 

.2BYTE 

_NOTYET 

# 

Bin 

Switch to binary 

KEY_ 

_H43 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H44 : 

.2BYTE 

_NOTYET 

# 


Unassigned 

KEY_ 

_H45 : 

.2BYTE 

_NOTYET 

# 


Unassigned 


Actually, this is a little tricky to explain and the real power of this 
scheme won’t become fully apparent until we implement the body of the 
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calculator in Lab 5e. For the moment, let’s simply note that, by means of 
these statements, we’ve managed to associate target subroutine addresses 
with a series of labels that will eventually correspond to the various keys 
on the calculator’s keypad. 

In order to visualize how this all hangs together, first use the assem¬ 
bler’s File > Assemble command to save this latest version of the skele¬ 
ton program and assemble it. Next, use the assembler’s Window > View 
List File command to look at the list file associated with this current ver¬ 
sion of the program. 

The format and use of the list file was discussed in Lab 2f If you 
scroll down to the “Subroutines” section of the list file, you should see 
something like the following: 

00 055 ############################################################### 
00056 ## Start of subroutines ## 

00 057 ############################################################### 
00058 


00059 

400D 

CF 

GETSTUFF: 

RTS 

00060 

400E 

CF 

GETNUM: 

RTS 

00061 

400F 

CF 

DISPNUM: 

RTS 

00062 

4010 

CF 

DISPERR: 

RTS 

00063 

4011 

CF 

CHK2NEG: 

RTS 

00064 





00065 

4012 

CF 

_NOTYET: 

RTS 

00066 

4013 

CF 

_ADD: 

RTS 

00067 

4014 

CF 

_SUB: 

RTS 

00068 

4015 

CF 

_MULT: 

RTS 

00069 

4016 

CF 

_DIV: 

RTS 

00070 

4017 

CF 

_NEG: 

RTS 


00071 

00072 ############################################################### 
00073 ## End of subroutines ## 

00074 ############################################################### 

For the purposes of these discussions, we will refer to the line num¬ 
bers and memory addresses in our list file (your line numbers and other 
aspects of this file may be slightly different, depending on how closely 
you’ve followed our instructions, but the overall “feel” should be the 
same). 

As an example, observe that the first instruction in the _add sub¬ 
routine occurs at address $4013 (on line 00066). Now scroll further 
down the list file to the redirection statements we entered in the “Global 
Data” area of the program: 
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00097 ########## Start of cunning re-direction 


00098 

4097 

40 

17 

KEY_H14; 

.2BYTE 

_NEG 

00099 

4099 

40 

12 

KEY_H15; 

.2BYTE 

_NOTYET 

00100 

409B 

40 

13 

KEY_H16; 

.2BYTE 

_ADD 

00101 

409D 

40 

14 

KEY_H17: 

.2BYTE 

_SUB 

00102 

409E 

40 

15 

KEY_H18; 

.2BYTE 

_MULT 

00103 

40A1 

40 

16 

KEY_H19; 

.2BYTE 

_DIV 


etc. 

Observe the label key_h16 (“the key whose code is hexadecimal $16”) 
located on line 00100. If you look at the calculator’s keypad (as illustrat¬ 
ed in Lab 2d), you’ll see that this key corresponds to the “-t-” function. 
This label occurs at address $409B, but that’s of little interest to us at the 
moment. What is of interest is the fact that the assembler has automati¬ 
cally loaded the 2-byte data value associated with this label with the start 
address of the _add subroutine at address $4013. 

The way this works is that, while analyzing the source file, the as¬ 
sembler automatically replaces any labels with their corresponding val¬ 
ues. Thus, when the assembler sees the following statement: 

KEY_H16: .2BYTE _ADD 

it automatically replaces the _ADD label with the start address of the 
_ADD subroutine. We could have achieved exactly the same effect by ex¬ 
plicitly entering this address in our source code as follows: 

KEY_H16: .2BYTE $4013 

The problem with doing things explicitly is that we don’t know what this 
address is going to be until we’ve assembled the program. Furthermore, 
as we add more lines of code to the program, the start addresses of the 
various subroutines will wander around all over the place. Thus, the cool 
thing about our scheme is that, irrespective of any changes we make to 
the source code, whenever we reassemble our program, the 2-byte data 
value associated with label key_h16 will always point to the first instruc¬ 
tion in the _ADD subroutine. 

Spend a few moments pondering this, but don’t worry unduly if you 
find it a little tricky to wrap your brain around this concept because all will 
be revealed in Lab 5e. When you are ready, use the assembler’s Window > 
View Source File command to return to the source file and continue to 
build the framework program as discussed in the following labs. 




Lab 

5b 


Objective: To augment our calculator framework program with 

some low-level utility subroutines. 

Duration: Approximately 30 minutes. 

Adding the GETSTUFF Routine 

The first of the simple utility routines we are going to need is one that 
will accept and store a sequence of keystrokes from the calculator’s 
keypad. 

For the purposes of our first-pass calculator, we are going to adhere 
to the KISS principle (“Keep it simple, stupid!”). The idea here is that we 
are going to create a low-level input routine called getstuff whose sole 
task in life is to read keystrokes from the calculator’s keypad and store 
them as a series of codes in the 10-byte temporary global variable called 
INSTRING we reserved in the previous lab. 

It’s important to note that our GETSTUFF routine is not going 
to perform any serious error checks on the key codes as they come in; 
instead, it will blindly store any codes it receives until the Enter key 
is pressed. 

Before you do anything else, use the assembler to open the 
LabSa.asm file you created in the previous lab and save it out as 
LabSb.asm. Now scroll down to the “Subroutines” section, delete the line 
containing the statement that says “getstuff : rts” and replace it with 
the following routine: 

########## Start of GETSTUFF subroutine 

########## Read a series of codes from the keypad until 

########## the "Enter" key is pressed 
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########## 

Initialize the input 

string with dummy values 

GETSTUFF: 

BLDX 


10 

# 

Load the index register with 10 


LDA 


$FF 

# 

Load ACC with $FF 

_GS_ISTR: 

DECK 



# 

Decrement the index reg 


STA 


[INSTRING,X] 

# 

Store ACC in string 


JNZ 


[_GS_ISTR] 

# 

Jump back if index reg not zero 

########## 

Initialize the "first" 

flag with 1 

_GS_IFST: 

LDA 


$01 

# 

Load ACC with 1 (meaning "first") 


STA 


[_GS_FST] 

# 

Store this value into the flag 

########## 

This 

is 

the main loop where we load a series of key codes 

########## 

into 

'INSTRING' until the enter key is pressed 


BLDX 


0 

# 

Load the index register with 0 

########## 

Wait 

for a key to be 

pressed 

_GS_LOOP: 

LDA 


[KEYPAD] 

# 

Load accumulator from keypad 


JN 


[_GS_LOOP] 

# 

Jump back if no key pressed 


STA 


[_GS_TEMP] 

# 

Store this code in temp location 

########## 

If this 

is the first 

key, then clear the display 

_GS_TFST: 

LDA 


[_GS_FST] 

# 

Retrieve the "first" flag 


JZ 


[_GS_DOIT] 

# 

Jump if 0 (not the first key) 


LDA 


CLRCODE 

# 

Otherwise load ACC with clear code 


STA 


[MAINDISP] 

# 

store to main display 


LDA 


$00 

# 

then load ACC with 0 


STA 


[_GS_FST] 

# 

and set "first" flag to "not first" 

########## 

Process 

the key 



_GS_DOIT: 

LDA 


[_GS_TEMP] 

# 

Retrieve the key code from temp 


CMPA 


ENTERKEY 

# 

Compare to code for 'Enter" key 


JNZ 


[_GS_STOR] 

# 

if not the same store it 


RTS 



# 

else return from this routine 

_GS_STOR: 

STA 


[INSTRING,X] 

# 

Else store this code in string 


INCX 



# 

Increment the index register 


CMPA 


$09 

# 

Compare code to that for number '9' 


JC 


[_GS_LOOP] 

# 

If code is bigger, don't display 


STA 


[MAINDISP] 

# 

else copy code to main display 


JMP 


[_GS_LOOP] 

# 

then wait for next key 

_GS_FST: 

.BYTE 



# 

Flag to indicate first character 

_GS_TEMP: 

.BYTE 



# 

Just a temp location 

########## 

End of 1 

GETSTUFF subroutine 

#- 

— 



- 

- # 


Unlike most of our subroutines, in this case we don’t have to start 
by popping a return address off the top of the stack, because this routine 
doesn’t actually use the stack per se. 
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Thus, the first thing we do when we enter the routine is to load the 
index register with 10 and the accumulator with a dummy (non-key- 
code) value of $FF. We then enter a short loop at label _GS_istr (“ini¬ 
tialize string”) in which we load our 10-byte iNSTRiNG with a series of 
these $FF codes. 

Next, at label _GS_ifst (“initialize first”), we load the accumula¬ 
tor with 1 and store this value in a temporary location called _GS_fst 
(“first”). As we shall see, we’re going to use this flag to tell us whether or 
not we’re processing the first key in a sequence. The reason for this is 
that we wish to leave whatever value is on the display until we start to en¬ 
ter a new value, at which point we will need to clear the display. 

When we reach the main loop at label _GS_LOOP, we cycle around, 
reading from the keypad and waiting for a key to be pressed. When a 
key is pressed, we immediately squirrel that code away in a temporary 
location. 

Next, at label _GS_tfst (“test for first”), we reload our “first” flag. 
If this flag already contains a 0, we know this is not the first key in the se¬ 
quence, so we jump to label _GS_doit. Otherwise, if the flag contains 1, 
then this is the first key in the sequence, in which case we clear the main 
display and load the “first” flag with 0. 

When we arrive at label _GS_D0IT, we retrieve the original key 
code from its temporary location and compare it to the code for the 
Enter key. If the codes are the same, we immediately return from this 
subroutine; otherwise we store the code in the appropriate position in 
INSTRING. Furthermore, so long as the key code is less than or equal to 
$09 (which means it corresponds to a decimal digit in the range “0” to 
“9”), we copy this value back to the calculator’s main display. 

Implications with regard to the usage model 

The simplicity of the getstuff routine presented above is going to dra¬ 
matically affect our calculator’s usage model, because it will force the 
user to press the Enter key after every number and every operator. For 
example, consider the following equation: 

30 * 3 -t- 8 = 92 {Infix notation} 

We’ve shown this using a conventional infix notation in order to get the 
idea across. As we discussed in Chapter 5, however, our first-pass calcu¬ 
lator is going to be based on a postfix notation known as reverse Polish 
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notation (RPN). In this case, the operands and operators maybe entered 
as follows: 

8 30 3 * + {Postfix (RPN) notation} 

Based on our discussions above, the way in which our getstuff 
routine works means that the user will have to click the Enter key after 
each number and each operator, so the actual keystrokes required to 
execute this calculation will be as follows: 

[8] [Enter] [3] [0] [Enter] [3] [Enter] [*] [Enter] [+] [Enter] 

Some of the very early calculators employed just such a usage model. 
However, this is obviously somewhat unwieldy, so at some stage in the 
future, you may decide to enhance our input routines so as to: 

a) Not require the Enter key to be pressed after each operator 

b) Allow operators like +, -, *, and/to automatically indicate the end of 
a number without the need to press the Enter key. 

This will increase the complexity of the code, but it will also make the 
calculator much easier to use because our equation could now be entered 
using fewer keystrokes as follows: 

[8] [Enter] [3] [0] [Enter] [3] [*] [+] 

But, once again, such enhancements are for the future. At the moment, 
we will just have to learn to be satisfied with the limitations of our simple 
input routines. 

Adding the DISPERR Routine 

This is going to be exactly the same disperr (“display error”) routine 
that we used in Lab 4a, so we won’t discuss it in detail here. All we need 
say is to scroll down to the “Subroutines” section of our framework pro¬ 
gram, delete the line containing the statement that says “DISPERR: RTS” 
and replace it with the following routine: 

########## Start of DISPERR subroutine 

########## Display an error message and then quit the program 
########## First clear the display 

DISPERR: LDA CLRCODE # Load ACC with clear code 

STA [MAINDISP] # and copy it to the main display 
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########## 

Display 

the word "Error: " (note the space) 

_DE_ERR: 

BSTX 

[TEMPX] 

# Store X reg in temp location 


BLDX 

MSG_000 

# Load X reg with start of msg 000 

_DE_LUPA: 

LDA 

[0,X] 

# Load a character from the msg 


JZ 

[_DE_MSG] 

# If it's a NUL jump to next bit 


STA 

INCX 

[MAINDISP] 

# otherwise copy it to main display 

# Increment the index register 


JMP 

[_DE_LUPA] 

# Jump back for next character 

########## 

Now display the main 

error message then terminate 

_DE_MSG: 

BLDX 

[TEMPX] 

# Reload X reg from temp location 

_DE_LUPB: 

LDA 

[ 0 ,x] 

# Load a character from the msg 


JZ 

[$0000] 

# If it's a NUL terminate the program 


STA 

INCX 

[MAINDISP] 

# otherwise copy it to main display 

# Increment the index register 


JMP 

[_DE_LUPB] 

# Jump back for next character 

########## 

End of DISPERR subroutine 

#- 

— 

— 

- # 


As we previously noted in Lab 4a, we are not concerned with 
storing the return address in this case because once the disperr rou¬ 
tine has finished displaying the required message it will terminate the 
program. 


Adding the _NOTYET Routine 

At last, an easy one! This is the routine that will be called if the user clicks 
on a function key that hasn’t been implemented yet, in which case we 
simply wish to display an appropriate error message and terminate the 
program. 

Scroll down to the “Subroutines” section of our framework pro¬ 
gram, delete the line containing the statement that says “_notyet : rts” 
and replace it with the following routine: 

########## Start of _NOTYET subroutine (for non-implemented functions) 
########## Display an error message and then quit the program 

_NOTYET: BLDX MSG_010 # Load X reg with addr of message 

JSR [DISPERR] # Jump to display error subroutine 

########## End of _NOTYET subroutine 

# - # 







388 


LABS FOR CHAPTER 5 CREATING AN INTEGER CALCULATOR 


Adding the CHK2NEG Routine 

And last, but not least, we need to add the routine that will be used by 
the _ADD and _SUB routines to check that they don’t end up generating a 
value of-32,768. As you may recall, we created and used this CHK2NEG 
routine in Lab 4e. 

Furthermore, as we were planning ahead (we love it when a plan 
comes together), as part of that lab we saved a copy of this routine in the 
file int-check-32768.asm. Thus, all you have to do is to scroll down to the 
“Subroutines” section of our framework program and delete the line 
containing the statement that says “CHK2NEG: RTS.” 

Leave the cursor at the beginning of this now-blank line and use the 
assembler’s Insert > Insert File command to select and insert the con¬ 
tents of int-check-32768.asm. 

Finally, use the assembler’s File > Assemble command to save this 
latest copy of your work and ensure that we still haven’t introduced any 
glaring errors. 
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Creating a Decimal GETNUM 
("Get Number") Routine 


Objective: To augment our calculator framework program with a 

routine that converts a string of key codes into a 2-byte 
(16-bit) binary integer. 

Duration: Approximately 30 minutes. 


Introducing the GETNUM Routine 

When this routine is called, it assumes that our 10-byte instring con¬ 
tains one or more key codes corresponding to the decimal digits “0” 
through “9.” The task of this routine is to convert such a sequence of 
codes into an equivalent 2-byte (16-bit) binary integer. 

For example, let’s assume that, while under the control of the 
GETSTUFF routine discussed in Lab 5b, the user entered the following 
sequence of characters: 

[2] [6] [3] [Enter] 

Not surprisingly, this means that the contents of INSTRING will be as 
shown in Figure L5-1. 

Now, we know that the first three codes in instring are intended to 
represent the decimal number 263^0 (“two hundred and sixty-three”). 

(The remaining $FF codes are just dummy values of no interest to us here.) 
This equates to 0107igin hexadecimal or 0000 0001 0000 01II 2 in binary. 

The trick, of course, is to manipulate the individual key codes in 
such a way as to form the equivalent binary number. There are a number 
of ways in which we might set about achieving this, the simplest of which 
involves multiplication. 

The idea here is that we start with a 2-byte temporary value con¬ 
taining all zeros. We next enter a loop in which, for each key code in se- 
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10-byte INSTRING 



Figure L5-1. Example contents of instring. 


quence, we multiply the temporary value by ten and then add in the val¬ 
ue of the key code. The easiest way to understand how this works is to 
consider the progression shown in Figure L5-2. 


Key code = 2 

Initial value = 0 

<> 

Value = (Value x 

10) + 2 

o o 

O CN 

II II 

— 000016 

= 000216 

Key code = 6 

<> 

Value = (Value x 

10) + 6 

= 26io 

= 001 Ai6 

Key code = 3 

<> 

Value = (Value x 

10) + 3 

= 263io 

= 010716 


Figure L5-2. Building up the binary value. 


Another cunning trick 

Well, this seems easy enough, doesn’t it? All we need is some way to mul¬ 
tiply our 2-byte temporary value by ten. Also, we will require some way 
to add the resulting value to our key code. 

We know what you’re thinking. We already have the _mult and 
_ADD subroutines that we created during the course of the labs associated 
with Chapter 4. You are right; we could use these if we really wanted to, 
but multiplication involves performing a lot of instructions. Surely, we 
can come up with something just a little more chic. 

You’ve hit the nail on the head. It’s time for yet another cunning 
trick. As we’ve noted, we wish to multiply our temporary value by ten. 
But hold hard, because this is equivalent to multiplying the value by 
eight and by two and adding the results together; for example: 


Starting with: 

This is the same as saying: 
Which is the same as saying: 


Value = Value * 10 
Value = Value * (8 + 2) 

Value = (Value * 8) + (Value * 2) 















INTRODUCING THE GETNUM ROUTINE 


391 


The point of all of this is that, from Chapter 4, we know that multiplying 
a binary value by two can be achieved by shifting it one bit to the left. 
Similarly, multiplying a binary value by eight can be achieved by shifting 
it three bits to the left. 

The GETNUM routine itself 

Using the cunning stratagem discussed above means that we can create a 
reasonably elegant decimal getnum routine as follows: 


########## 

Start 

of 

decimal GETNUM subroutine 

########## 

Assumes 

INSTRING contains one or more decimal digits 

########## 

Pop the . 

return address 

off the stack and save it 

GETNUM: 

POPA 



# 

Pop the MS byte of return address 


STA 


[_GN_RADD] 

# 

off the stack and store it 


POPA 



# 

Pop the LS byte of return address 


STA 


[_GN_RADD+1] 

# 

off the stack and store it 

########## 

Initialize temp 2-byte 

value and index register 

_GN_INIT: 

BLDX 


0 

# 

Load the index register with 0 


LDA 


0 

# 

Load ACC with 0 


STA 


[_GN_TMPA] 

# 

Clear MS byte of temp location 


STA 


[_GN_TMPA+1] 

# 

Clear LS byte of temp location 

########## 

Start 

of 

main loop 



_GN_DOIT: 

LDA 


[INSTRING,X] 

# 

Load the next key code 


JN 


[_GN_STA] 

# 

If code = $FF we're done 

########## 

Multiply 

by 2 and store in two locations 

_GN_ML2: 

LDA 


[_GN_TMPA+1] 

# 

Load LS byte of temp value 


SHL 



# 

shift left by 1 bit 


STA 


[_GN_TMPA+1] 

# 

store it in LS 1st temp value 


STA 


[_GN_TMPB+1] 

# 

also store in LS 2nd temp value 


LDA 


[_GN_TMPA] 

# 

Load MS byte of temp value 


ROLC 



# 

rotate left by 1 bit 


STA 


[_GN_TMPA] 

# 

store it in MS 1st temp value 


STA 


[_GN_TMPB] 

# 

also store in MS 2nd temp value 

########## 

Multiply 

main location 

by 4 and store it 

_GN_ML4: 

LDA 


[_GN_TMPA+1] 

# 

Load LS byte of temp value 


SHL 



# 

shift left 1 bit 


STA 


[_GN_TMPA+1] 

# 

store it 


LDA 


[_GN_TMPA] 

# 

Load MS byte of temp value 


ROLC 



# 

rotate left by 1 bit 


STA 


[_GN_TMPA] 

# 

store it 
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LDA 

[_GN_TMPA+1] 

# 

Load LS byte of temp value 


SHE 


# 

shift left 1 bit 


STA 

[_GN_TMPA+1] 

# 

store it 


LDA 

[_GISI_TMPA] 

# 

Load MS byte of temp value 


ROLC 


# 

rotate left by 1 bit 


STA 

[_GN_TMPA] 

# 

store it 

########## 

Add the 

value multiplied by 2 to the value multiplied by 8 

_GN_AMUL: 

LDA 

[_GN_TMPA+1] 

# 

Load LS byte of x8 


ADD 

[_GN_TMPB+1] 

# 

add (no carry) LS byte x2 


STA 

[_GN_TMPA+1] 

# 

and store the result 


LDA 

[_GN_TMPA] 

# 

Load MS byte of x8 


ADDC 

[_GN_TMPB] 

# 

add (with carry) MS byte x2 


STA 

[_GN_TMPA] 

# 

and store the result 

########## 

Add the 

value of the 

key code in 

_GN_AKEY: 

LDA 

[INSTRING,X] 

# 

Load ACC with key code 


ADD 

[_GN_TMPA+1] 

# 

add (no carry) the LS temp value 


STA 

[_GN_TMPA+1] 

# 

and store the result 


LDA 

$00 

# 

Load ACC with 0 


ADDC 

[_GN_TMPA] 

# 

add (with carry) the MS temp value 


STA 

[_GN_TMPA] 

# 

and store the result 

########## 

Increment the index 

register and do it all again 

_GN_INCX: 

INCX 


# 

Increment the index register 


JMP 

[_GN_DOIT] 

# 

Jump back to look at the next code 

########## 

Store the 2-byte binary number on the stack 

_GN_STA: 

LDA 

[_GN_TMPA+1] 

# 

Load ACC with LS byte of number 


PUSHA 


# 

Push it into the stack 


LDA 

[_GN_TMPA] 

# 

Load ACC with MS byte of number 


PUSHA 


# 

Push it into the stack 

########## 

Return 

gracefully from 

this subroutine 

_GN_RET: 

LDA 

[_GN_RADD+1] 

# 

Get LS byte of return address from 


PUSHA 


# 

temp location and push onto stack 


LDA 

[_GN_RADD] 

# 

Get MS byte of return address from 


PUSHA 


# 

temp location and push onto stack 


RTS 


# 

Return from this subroutine 

_GN_RADD: 

.2BYTE 


# 

2-byte temp location used to store 




# 

the return address for this routine 

_GN_TMPA: 

.2BYTE 


# 

One 2-byte temp location 

_GN_TMPB: 

.2BYTE 


# 

Another 2-byte temp location 

########## 

End of 

GETNUM subroutine 

#- 

— 

— 


- # 
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We can race through this routine really quickly. The first thing 
we do when we enter the routine at label getnum is to pop the return 
address off the stack and store it away. 

Next, at label _GN_INIT (“initialize”) we load the index register 
with 0 (to point it at the first key code in instring) and we load a 
2-byte temporary location called _gn_tmpa with zeros. 

And as quickly as that we’ve reached the start of this routine’s main 
loop at label _gn_doit. We commence by loading the key code pointed 
to by the index register and check it to see if it’s a digit or a dummy ($FF) 
value. If it’s a dummy value we’re finished, in which case we jump direct¬ 
ly to label _GN_STA (“store the number”). Otherwise, we fall through to 
label _GN_ML2 (“multiply by 2”), where we shift the value in our 2-byte 
location 1 bit to the left, thereby multiplying it by two. Observe that we 
store the result in our main _GN_TMPA temporary location and also in an 
additional temporary location called _GN_TMPB. 

Next, at label _gn_ml4 (“multiply by 4”), we shift the value in our 
main temporary location left by two more bits, thereby multiplying it by 
four. This means that, as we previously multiplied it by two and now 
we’ve further multiplied it by four, the main location has now been mul¬ 
tiplied by 2 X 4 = 8. 

When we reach label _gn_amul (“add the multiplied values to¬ 
gether”), we add the contents of our two 2-byte temporary locations 
together and store the result in the main location at _GN_TMPA. Thus, 
this location now contains its original value multiplied by ten. 

And then we come to label _gn_akey, where we add the binary 
code associated with the key into our main temporary location. Of 
course, the key code itself occupies only 1 byte, whereas the temporary 
location is two bytes, but we can get around this by adding $00 to the MS 
byte of the temporary location (along with the carry from the addition of 
the LS bytes). 

All that happens at label _GN_INCX is that we increment the con¬ 
tents of the index register to point to the next key code and then we jump 
back to the beginning of the loop. 

Once we’ve processed the final key code, we find ourselves at 
label _GN_STA (“store the number”), at which point we push our 
2-byte integer onto the top of the stack. Finally, at label _gn_ret, 
we push the return address back onto the stack and exit from this 
subroutine. 
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Adding the GETNUM routine into the framework 

Use the assembler to open the LabSb.asm file you created in the previous 
lab and save it as LabSc.asm. Now scroll down to the “Subroutines” sec¬ 
tion, delete the line containing the statement that says “getnum: rts” 
and replace it with the GETNUM routine described above. 

You know the drill by now. Use the assembler’s File > Assemble 
command to save this latest copy of your masterpiece and ensure that 
everything remains error-free. 



01000010101101010010010010001101100000EIEEE 

Creating a Decimal DISPNUM 
("Display Number") Routine 


Objective: To augment our calculator framework program with a 

routine that pops a 2-byte (16-bit) signed binary integer 
off the top of the stack and displays it as a decimal value. 
Duration: Approximately 30 minutes. 


Introducing the DISPNUM Routine 

When this routine is called, it assumes that there is at least one 2-byte 
signed binary number on the top of the stack. The task of the dispnum 
routine is to pull a copy of this value off the top of the stack, convert it 
into an equivalent series of decimal character codes, and present these 
codes to the calculator’s main display. 

There are two key points to remember here: 

a) The dispnum routine needs to leave a copy of the original number 
on the top of the stack, because this number may well be required by 
subsequent routines. 

b) The value pulled from the top of the stack will be a signed binary 
number, which means that it may be positive or negative. If the value 
is negative, the getnum routine must first display a minus char¬ 
acter; then it will convert its copy of the number into its positive 
counterpart; and finally it will translate this positive value into the 
decimal character codes for display. 

As usual, there are a number of techniques we might use to convert 
a binary number into a series of decimal characters. For example, we 
could use a divide-by-ten approach. In this case, we would take our orig¬ 
inal binary value and divide it by ten; then the remainder from this oper¬ 
ation would represent the least-significant decimal digit to be displayed. 
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Value 

Value 

Value 


We would then divide our new binary value by ten, and the re¬ 
mainder from this operation would represent the next least-significant 
digit to be displayed. We could proceed in this vein until we had extract¬ 
ed all of the digits. The only twist here is that we would eventually have 
to display the decimal digits in the reverse order to that in which we ex¬ 
tracted them. In order to visualize what we mean by this, consider the 
progression shown in Figure L5-3. 

In this case, we start with a binary value of 0000 0001 0000 011 12 , 
which equates to 263 jo in decimal. When we divide this value by ten, we 
end up with a new binary value of 0000 0000 0001 IOIO 2 (which equates 
to 26io in decimal), along with a remainder of 00112 (which equates to 
3 10 in decimal). 

By continuing to perform this operation until the main value is 
zero, we end up extracting remainders of 3io, 610 , and We would 
then need to offer these values to the calculator’s display in their reverse 
order so as to present a final value of 263. 

Yet another cunning ploy 

The above technique seems relatively easy, doesn’t it? We’ve already cre¬ 
ated a 2-byte _Div (“divide”) routine in Lab 4g. In the case of that rou¬ 
tine, we used the remainder to perform a rounding operation and then 
threw it away. But it wouldn’t take a vast amount of effort to create a 
modified version of the routine that omitted the rounding function and 
returned a 1 -byte remainder. 

Once again, however, functions such as multiplication and divi¬ 
sion are expensive in terms of the large number of instructions they 


Initial value = 0000 0001 0000 0111 2 = 



Quotient 


= (Value 

/ 10 ) 

= 0000 

0000 

0001 

1010 2 = 







= (Value 

/ 10 ) 

= 0000 

0000 

0000 

0010 2 = 







= (Value 

/ 10 ) 

= 0000 

0000 

0000 

0000 2 = 


Figure L5-3. Extracting 


010716 = 263io 

Remainder 

\ / ^ \ 

001 Ai6 = 2610 0011 2 = 0003 16 = 3io 

0002 16 = 2io OIIO 2 = OOO 616 = 610 

0000 16 = O 10 OOIO 2 = 0002 16 = 2io 

the decimal digits. 
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have to perform. Could we possibly come up with yet another clever 
ruse? 

Actually, the solution we are going to use here really isn’t all that 
cunning, because it simply involves performing a series of subtractions. 
Due to the fact we’re working with 2-byte (16-bit) values, we know that 
the largest positive number we’re going to have to handle is 32,767io- 
This means that we can begin by subtracting 10,000io from our original 
value and keeping track of how many times we can do this before the val¬ 
ue goes negative. 

When the value does go negative, we add 10,000io back into the 
main number and display the number of times we successfully subtract¬ 
ed the 10,000io. We then repeat this process for values of l,000io> 100io> 
lOjoi and IjQ. 

For example, in the case of a number like 26,847io, repeatedly sub¬ 
tracting 10,000io> then l,000io> then lOOio, then lOjo will result in the fol¬ 
lowing (as we shall discover, we don’t actually need to perform any sub¬ 
tractions in the case of the final units value): 

2io X 10,000io 

610 X l,000jo 

810 ^ lOOio 

4io X lOio 

7io ^ lio 

Then, all we need to do is to present the codes 2, 6, 8, 4, and 7 to the 
main display, which will therefore show the following: 

26847 

There is one slight “gotcha” we need to keep in mind with regard to 
any zero values. In the case of a number such as 6,847 io> for example, the 
algorithm described above will result in the following: 

Oio X 10,000io 

610 X l,000jo 

810 ^ lOOio 

4io X lOio 

7io ^ lio 
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In this case, we do not wish to present the codes 0, 6, 8, 4, and 7 to the 
main display, because this would result in the following: 

06847 

This means that we have to introduce a rule that we will not display any 
leading Os. That is, we will not display a 0 unless we’ve previously dis¬ 
played a nonzero value. However, “there is an exception to every rule,” 
as they say, and the exception to this one occurs in the units (Is) column. 
In this case, we will always display the quantity of Is, even if that quantity 
is zero. The reason for doing this is that the value we are trying to display 
may well be 0io> in which case we will wish to see a single 0 appear on the 
calculator’s main display. 

The DISPNUM routine itself 

Using the technique discussed above means that we can create a reason¬ 
ably simple decimal DISPNUM routine that uses relatively few instruc¬ 
tions. All we need to keep in mind are the following decimal to hexadeci¬ 
mal to binary equivalent values: 


Decimal 

Hexadecimal 

Binary 

10,000io 

2710i6 

0010 0111 0001 OOOO 2 

l,000jg 

03E8i6 

0000 0011 1110 IOOO 2 

O 

o 

0064i6 

0000 0000 0110 OIOO 2 

lOio 

OOOAis 

0000 0000 0000 IOIO 2 


########## Start of decimal DISPNUM subroutine 
########## Assumes a 2-byte integer is on top of the stack 


########## Pop 1 
DISPNUM: POPA 

STA 
POPA 
STA 


return address 
# 

[_DN_RADD] # 
# 

[_DN_RADD+1] # 


off the stack ai 
Pop the MS byte 
off the stack 
Pop the LS byte 
off the stack 


id save it 
of return address 
and store it 
of return address 
and store it 


########## Clear the main display 

_DN_CDIS: LDA CLRCODE # Load ACC with clear code 

STA [MAINDISP] # and copy to main display 

########## Initialize the "first" flag with 1 

_DN_IFST: LDA $01 # Load ACC with 1 (meaning "first") 

STA [_DN_FST] # Store this value into the flag 
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########## 

Pop the 

number off 

the 

top of the stack 


_DN_GNUM: 

POPA 


# 

Pop the MS byte of number 



STA 

[_DN_TMP] 

# 

off the stack and store it 



POPA 


# 

Pop the LS byte of number 



STA 

[_DN_TMP+1 

] # 

off the stack and store it 


########## 

Push a copy of the 

number back onto the stack 


_DN_PNUM: 

PUSHA 


# 

Push LS byte of number onto stack 


LDA 

[_DN_TMP] 

# 

Retrieve MS byte of number 



PUSHA 


# 

and push it onto the stack 


########## 

Display 

'-' and invert 

number if necessary 


_DN_INV: 

JNN 

[_DN_DOIT] 

# 

Jump if the value isn't negative 


LDA 

$2D 

# 

else load ASCII code for minus sign 


STA 

[MAINDISP] 

# 

and store to main display 



LDA 

$00 

# 

Load ACC with 0 



SUB 

[_DN_TMP+1 

] # 

subtract (no carry) LS byte 

of 


STA 

[_DN_TMP+1 

] # 

number and store it 



LDA 

$00 

# 

Load ACC with 0 



SUBC 

[_DN_TMP] 

# 

subtract (with carry) MS byte of 


STA 

[_DN_TMP] 

# 

number and store it 


########## 

Subtract the different 

powers of ten 


_DN_DOIT: 

BLDX 

$2710 

# 

Load X reg with $2710 (10,000) 



JSR 

[_DN_NEST] 

# 

and call nested subroutine 



BLDX 

$03E8 

# 

Load X reg with $03E8 (1,000) 



JSR 

[_DN_NEST] 

# 

and call nested subroutine 



BLDX 

$0064 

# 

Load X reg with $0064 (100) 



JSR 

[_DN_NEST] 

# 

and call nested subroutine 



BLDX 

$000A 

# 

Load X reg with $000A (10) 



JSR 

[_DN_NEST] 

# 

and call nested subroutine 


########## 

Display 

the number 

of Is irrespective of its value 


_DN_01: 

LDA 

[_DN_TMP+1 

] # 

Load ACC with LS number (Is) 



STA 

[MAINDISP] 

# 

and display it 


########## 

Return gracefully . 

from 

the main DISPNUM subroutine 


_DN_RET: 

LDA 

[_DN_RADD+1] # 

Get LS byte of return address 

from 


PUSHA 


# 

temp location and push onto 

stack 


LDA 

[_DN_RADD] 

# 

Get MS byte of return address 

from 


PUSHA 


# 

temp location and push onto 

stack 


RTS 


# 

Return from this subroutine 


########## 

This is 

the Start < 

of the nested subroutine that repeatedly 

########## 

subtracts the power of 

10 (passed in via the X reg) 


_DN_NEST: 

BSTX 

[_DN_TMPX] 

# 

Store contents of index reg 



BLDX 

0 

# 

Load index register with 0 
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########## 

Subtract 

. the power of 10 from the number 

_DN_SUB: 

LDA 

[_DIS[_TMP+1] 

# 

Load ACC with LS number 


SUB 

[_DN_TMPX+1] 

# 

subtract (no carry) LS power of 10 


STA 

[_DN_TMP+1] 

# 

and store result 


LDA 

[_DN_TMP] 

# 

Load ACC with MS number 


SUBC 

[_DN_TMPX] 

# 

subtract (w carry) MS power of 10 


STA 

[_DN_TMP] 

# 

and store it 


JNC 

[_DN_ADD] 

# 

If carry = 0 then recover 


INCX 


# 

else increment index reg 


JMP 

[_DN_SUB] 

# 

and go for it again 

########## 

We've gone too far, 

so 

add power of 10 back in again 

_DN_ADD: 

LDA 

[_DIS[_TMP+1] 

# 

Load ACC with LS number 


ADD 

[_DIS[_TMPX+1] 

# 

add (no carry) LS power of 10 


STA 

[_DIS[_TMP+1] 

# 

and store result 


LDA 

[_DN_TMP] 

# 

Load ACC with MS number 


ADDC 

[_DN_TMPX] 

# 

add (w carry) MS power of 10 


STA 

[_DN_TMP] 

# 

and store it 

########## 

Test to 

see if this 

is 

the first digit to be displayed 

_DN_TSTF: 

BSTX 

[_DIS[_TMPX] 

# 

Store the index register 


LDA 

[_DN_FST] 

# 

Load the first flag 


JNZ 

[_DN_TSTZ] 

# 

If 1 (first) then jump to test for 0 


LDA 

[_DIS[_TMPX+1] 

# 

else load ACC with LS X 


STA 

[MAINDISP] 

# 

store to main display 


RTS 


# 

and return to main routine 

########## 

If this 

is the first 

digit, test for a non-zero value 

_DN_TSTZ: 

LDA 

[_DN_TMPX+1] 

# 

Load ACC with LS byte of X reg 


JNZ 

[_DN_DFST] 

# 

if non-0 jump to display 


RTS 


# 

else return to main routine 

_DN_DFST: 

STA 

[MAINDISP] 

# 

Store code to main display 


LDA 

$00 

# 

then load ACC with 0 


STA 

[_DN_FST] 

# 

and store it to "first" flag 


RTS 


# 

and return to main routine 

########## 

This is 

the end of the 

nested subroutine 

_DN_RADD; 

.2BYTE 


# 

2-byte temp location used to store 




# 

the return address for this routine 

_DN_TMP: 

.2BYTE 


# 

A 2-byte temp location 

_DN_TMPX: 

.2BYTE 


# 

A 2-byte temp location for the X reg 

_DN_FST: 

.BYTE 


# 

A 1-byte temp location 

########## 

End of DISPNUM subroutine 

#- 


— 


- # 


Fear not! We know the above looks a bit “hairy,” but, as usual, it’s 
nowhere near as bad as it seems. We commence by performing a few 
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simple housekeeping tasks. When we enter the routine at label dispnum, 
we pop the return address off the stack and store it away. Next, at label 
_DN_CDis (“clear display”), we write a clear code to the display to re¬ 
move any value that is already on display. And when we get to label 
_DN_IFST (“initialize first flag”) we load a flag called _dn_fst (“first”) 
with a 1 to indicate that we have not, thus far, displayed any characters 
(we’ll return to this point in a moment). 

At label _GN_GNUM (“get number”) we pop a copy of the 2-byte 
number off the top of the stack; then, at label _gn_pnum (“put number”) 
we push a copy back onto the stack for future use by other subroutines. 

When we arrive at label _DN_i]W (“invert”), we still have a copy of 
the MS byte of our number stored in the accumulator, so we test to see if 
this value is negative. In the case of a positive value, we immediately 
jump to label _dn_doit; otherwise, we write the ASCII code for a minus 
(“-”) character to the main display and convert the number into its posi¬ 
tive counterpart by subtracting it from zero. 

The fun really starts when we arrive at label _GN_D0IT. Now, pay 
attention and don’t blink, because if you’re not careful this will be a case 
of “the quickness of the hand deceives the eye” (note, however, that our 
hands never leave the ends of our arms). 

In a moment we’re going to introduce a nested subroutine called 
_DN_NEST. As we shall see, we need some way to pass a 2-byte value into 
this subroutine, and we’ve decided to use the index register (in a some¬ 
what unconventional role) for this purpose. All we need know at this 
point is that the _DN_NEST routine will take whatever value is passed in 
via the index register. It will loop around, subtracting this value from the 
main number; it will maintain a count of how many times the value can 
be subtracted; and, ultimately, it will present a decimal digit correspond¬ 
ing to this count value to the calculator’s main display. (Oh yes, it will 
also make sure not to display any leading zeros and it will make our 
smiles whiter and brighter!) 

Thus, as we see at label _dn_doit, we load the index register with 
$2710 (which corresponds to 10,000 jq in decimal) and call our nested 
_DN_NEST routine. We then repeat this process for values of $03E8 (or 
l,000io in decimal), $0064 (or lOOio in decimal), and $000A (or lOio in 
decimal). 

Once we’ve used the _dn_nest routine to display the digits corre¬ 
sponding to multiples of 10,000 io> 1.000io> lOO^o, and 10io> we arrive at 
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label _DN_01, at which point we display the digit corresponding to mul¬ 
tiples of 1 10 - Finally, at label _dn_ret, we push the return address for the 
main DISPNUM routine back onto the stack and exit from this routine. 

The nested _DN_NEST routine 

We shouldn’t boast, but this really is a surprisingly efficacious little rou¬ 
tine. We start by taking the value in the index register (this is the value 
we wish to subtract from the main number) and storing it in a temporary 
location called _DN_TMPX. Once we’ve stored this value, the index regis¬ 
ter is free to be used as a counter, so we initialize it to contain 0. 

At label _dn_SUB, we loop around, subtracting the 2-byte value in 
the _DN_TMPX location from our 2-byte number in the _DN_TMP loca¬ 
tion. Every time we successfully perform this subtraction without our 
main value going negative, we increment the contents of the index 
register. 

When the main value does go negative (indicated by a 0 in the carry 
(borrow) flag), we fall through to label _dn_add, at which point we add 
the 2-byte value in the _dn_tmpx location back into the 2-byte number 
in the _DN_TMP location. 

When we reach label _dn_tstf (“test for first”), we store the 
count value in the index register into our temporary location. Next we 
load the _dn_fst flag and test to see if it contains 1 (indicating that this 
is the first character to be displayed) or 0 (indicating that we’ve already 
displayed a character). 

If we have already displayed another character, then we immediate¬ 
ly display this character and return to the main routine. If this is the first 
character to be displayed, however, we jump to label _dn_tstz (“test 
for zero”). If the value is zero, we return to the main routine without dis¬ 
playing it; otherwise, we display the value, load the _dn_fst flag with 0 
to indicate that we have now displayed a character, and then return to the 
main routine. 

Adding the DISPNUM routine into the framework 

Use the assembler to open the LabSc.asm file you created in the previous 
lab and save it as LahSd.asm. Now scroll down to the “Subroutines” sec¬ 
tion, delete the line containing the statement that says “dispnum: rts” 
and replace it with the DISPNUM routine described above. 
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We’re almost there! We’re poised on the edge of excitement beyond 
our wildest dreams (it’s been a long day). In the next, and final (hurray!), 
lab we’re going to put the finishing touches to our program and actually 
perform some calculations. But before that happy event occurs, use the 
assembler’s File > Assemble command to save this penultimate copy of 
the little scamp and ensure that the term “error” is not one that sullies 
our vocabulary. 




Lab 

5e 


01000010101101010010010010001101100000EIEEE 

Implementing a Four- 
Function Integer Calculator 


Objective: To pull our existing math subroutines together to imple¬ 

ment a simple four-function integer calculator. 
Duration: Approximately 30 minutes. 


Inserting the Math Subroutines 

We’re almost ready to create the body of the calculator, but before we 
proceed, we need to incorporate our math subroutines into the frame¬ 
work program. 

Use the assembler to open the LabSd.asm file you created in the 
previous lab and save it as LabSe.asm. Now scroll down to the “Subrou¬ 
tines” section and delete the following lines: 


ADD: 

RTS 

# 

This 

will 

be 

our 

16-bit 

addition 

.SUB: 

RTS 

# 

This 

will 

be 

our 

16-bit 

subtraction 

.MULT: 

RTS 

# 

This 

will 

be 

our 

16-bit 

multiply 

.DIV: 

RTS 

# 

This 

will 

be 

our 

16-bit 

divide 

.NEG: 

RTS 

# 

This 

will 

be 

our 

16-bit 

negation 


Leave the cursor at the beginning of these now-blank lines and use the 
assembler’s Insert > Insert File command to select and insert the con¬ 
tents of the following files: 

int~add-2-byte-v2.asm This is the _ADD routine that we originally created 
in Lab 4b and then “tweaked” in Lab 4e. 
int-sub-2-byte-v2.asm This is the _SUB routine that we originally created 
in Lab 4c and then “tweaked” in Lab 4e. 

This is the _MULT routine that we originally 
created in Lab 4f. 


int-mult-2-hyte.asm 
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int-div-2-byte.asm This is the _DIV routine that we originally 

created in Lab 4g. 

int-neg-2-byte.asm This is the _NEG routine that we originally 

created in Lab 4d. 


Creating the Body of the 
Calculator Program 

Yes! This is it! We’ve traveled a long hard road together, but now we’re 
poised on the very brink of success. All we need do is to add the “secret 
squirrel sauce” that will enable our calculator perform its machinations. 
Can you hear the buzz of excitement and feel the tingle of anticipation? 

So, without further delay, scroll down to the “Body” section of the 
framework, delete the comment that says “## Main body will go here,” 
and replace it with the following statements: 


MAINLOOP: JSR 

[GETSTUFF] 

# 

Call routine to get some input 

LDA 

[INSTRING] 

# 

Load ACC with first code in INSTRING 

CMPA 

$09 

# 

Compare value in ACC with $09 

JC 

[DOFUNC] 

# 

If value in ACC > $09 then jump 

JSR 

[GETNUM] 

# 

else it's a number so get it 

JMP 

[MAINLOOP] 

# 

then jump back for more input 

########## Call 

the appropriate 

math/Other function/subroutine 

DOFUNC: SUB 

$14 

# 

Subtract offset from ACC 

SHL 


# 

Shift left {multiply by 2) 

STA 

[TEMPX+1] 

# 

Store in LS byte of temp X reg 

BLDX 

[TEMPX] 

# 

Load index register 

JSR 

[[KEY_H14,X] ; 

1# 

Call appropriate subroutine 

JSR 

[DISPNUM] 

# 

Call routine to display result 

JMP 

[MAINLOOP] 

# 

Jump back for more input 


“Surely this can’t be all there is to it!” you cry. But yes, it is! Let’s go 
through this from the top (as you can see, it won’t take long). We start at 
label MAINLOOP where we call our getstuff subroutine. As we know, 
this routine reads a series of key codes from the calculator’s keypad and 
stores them in our 10-byte instring until it sees the “Enter” key. 

Next, we load the accumulator with the first code from instring 
and compare it to a value of $09 to determine whether we are dealing 
with a number or a function key. If the value in the accumulator is 
greater than $09, it’s a function key, in which case we jump to the DO- 
FUNG (“do the function”) label. Otherwise, we call subroutine getnum. 




CREATING THE BODY OF THE CALCULATOR PROGRAM 


407 


which converts the string of decimal codes stored in iNSTRiNG into a 
2-byte binary integer and stores this value on the stack. Once we’ve con¬ 
verted this number, we jump back to the mainloop label to wait for the 
user to enter another number or function key. 

The clever part occurs when the user clicks on a function key and 
we jump to label dofunc. In order to understand what happens next, we 
need to cast our minds way back through the mists of time. As you may 
recall, in those days of yore we used to refer to as Lab 5a, we included the 
following statements toward the end of our framework program: 


KEY_ 

_H14 : 

.2BYTE 

_NEG 

# +/ 

Negate 

KEY_ 

_H15 : 

.2BYTE 

_NOTYET 

# . 

Decimal point 

KEY_ 

_H16 : 

.2BYTE 

_ADD 

# + 

Add 

KEY_ 

_H17 : 

.2BYTE 

_SUB 

# - 

Subtract 

KEY_ 

_H18 : 

.2BYTE 

_MULT 

# * 

Multiply 

KEY_ 

_H19 : 

.2BYTE 

_DIV 

#/ 

Divide 

KEY_ 

_H1A: 

.2BYTE 

_NOTYET 

# = 

Equals 

KEY_ 

_H1B: 

.2BYTE 

_NOTYET 

# ( 

Left parenthesis 

etc. 






The first of these 2-byte locations is identified by the key_h14 la¬ 
bel. This corresponds to the first function key in which we are interest¬ 
ed—the negate (+/-) key—whose associated code is $14. As we previous¬ 
ly discussed, the assembler will automatically load this 2-byte location 
with the start address of the _NEG subroutine. 

Similarly, in the case of the KEY_H15 label, which is associated with 
the decimal point key whose code is $15, the assembler will automatically 
load this 2-byte location with the start address of the _notyet subrou¬ 
tine. And so it goes. 

The point here is that, so long as we know the address of the first of 
these labels (the key_h14 label), we can easily calculate the address of 
any of the other labels. That is, the address of the key_h15 label is equal 
to the address of the key_h14 label -I- 2, the address of the key_h16 
label (which is associated with the _add subroutine) is equal to the 
address of the key_h14 label -I- 4, and so forth. 

Now let’s return to the doeung label in the main body of the pro¬ 
gram. When we reach this label, we know that the accumulator contains 
the code associated with one of our function keys. The first thing we do 
is to subtract $14 from this value. This means that if the user clicked the 
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key whose code is $14, the accumulator will now contain $00; if 
the user clicked the decimal point key whose code is $15, the accumu¬ 
lator will now contain $01; if the user clicked the “-I-” key whose code is 
$16, the accumulator will now contain 2; and so on. 

Stay with us now. The next thing we do is to shift the contents of 
the accumulator left by one bit, which is the same as multiplying this val¬ 
ue by two. Thus, if the user originally clicked the key, the accumu¬ 
lator will now contain $00 X 2 = $00; if the user clicked the decimal point 
key, the accumulator will now contain $01 X 2 = $02; if the user 
clicked the “-I-” key, the accumulator will now contain $02 X 2 = $04; and 
so on. 

Now, you may recall that when we originally created our frame¬ 
work, we reserved a 2-byte temporary variable called TEMPX and we 
loaded this with $0000. We now store the contents of the accumulator 
into the LS byte of this variable at address TEMPX+1. This means that if 
the user originally clicked the key, the tempx location will now 
contain $0000; if the user clicked the decimal point key, tempx will 
now contain $0002; if the user clicked the “-t-” key, tempx will now con¬ 
tain $0004; and so on. 

Next, we load the index register with the contents of tempx, and 
then we use the following statement: 

JSR [[KEY_H14,X]]# Call appropriate subroutine 

This JSR (“jump to subroutine”) is using a preindexed indirect address¬ 
ing mode. In this case, the CPU will first add the address of the key_h14 
label to the value in the index register. The CPU will then look at the 2- 
byte location pointed to by this address, and it will use the contents of 
this location as the target address. 


The ways in which the various addressing modes work are detailed in Appendix B. Also, the address- 
ing modes supported by the different instructions are summarized in Appendix C. 


For example, as we’ve already discussed, if the user clicks the “-I-” 
key whose code is $16, the index register will end up containing ($16 - 
$14) *2 = $0004. The CPU will then read the 2-byte value stored at the 
location whose address is equal to KEY_H14 -I- $0004. And this 2-byte 
value (which corresponds to the key_h16 label) is the address of the 
_ADD subroutine. 
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This does take a little thought to wrap your brain around things, 
but once it “clicks” you will say “wow, how capriciously cunning” (and 
you’ll be right!). 

And that’s pretty much it. As soon as we return from performing 
the appropriate math function, which will leave its 2-byte result on the 
top of the stack, we call the dispnum subroutine to display this value, 
and then jump back to MAINLOOP to wait for the next number or 
operator to be keyed in. 

Testing the Calculator Program 

Hold onto your socks, because here we go. Use the assembler’s File > 
Assemble command to assemble your masterpiece. Click the On/Off 
button on the front panel to power-up the calculator, use the Memory > 
Load RAM command to load the labSe.ram file into the calculator’s 
memory, and click the Run button to set the program running. 

The display clears and the calculator sits there waiting for us to per¬ 
form our first calculation. Remembering that our calculator is based on a 
reverse Polish notation (RPN) usage model, let’s try entering the following 
equation: 

123 456 

This is, of course, equivalent to entering 456 - lll-t-123ona standard 
pocket calculator using infix-based input routines, but we digress. In or¬ 
der to enter the above equation, we need to use the following keystrokes: 

[1] [2] [3] [Enter] [4] [5] [6] [Enter] [1] [1] [1] [Enter] 

[-] Enter [-I-] [Enter] 

Let’s take this step by step to see what happens. We’ll start with the fol¬ 
lowing keystrokes: 

[1] [2] [3] [Enter] 

As soon as we press the Enter key, the calculator places a 2-byte binary 
number containing the equivalent of 123 jq onto the top of the stack. 

Now continue with the following keystrokes: 


[4] [5] [6] [Enter] 
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Observe how the previous number remains on the display until you click 
the first of these number keys. This time, pressing the Enter key causes 
the calculator to place a 2-byte binary number containing the equivalent 
of 456io onto the top of the stack. Now key in the third value: 

[1] [1] [1] [Enter] 

On this occasion, pressing the Enter key causes the calculator to place a 2- 
byte binary number containing the equivalent of 111 lo onto the top of the 
stack. Thus, the stack currently contains three values [Figure L5-4(a)]. 

Now, let’s perform the first operation by entering the following 
keystrokes: 

[-] [Enter] 

This causes our _SUB routine to subtract lllio from 456io and leave the 
resulting 345io on the top of the stack [Figure L5-4(b)]. This is the value 
that is now presented to the display by our dispnum routine. 

Similarly, when we perform the second operation by entering the 
following keystrokes: 

[-t-] [Enter] 

This causes our _ADD routine to add 345io to 123^0 and leave the result¬ 
ing 468io on the top of the stack. And this is the value that is now pre¬ 
sented to the display by our DISPNUM routine [Figure L5-4(c)]. 

Now, let’s try negating this value by entering the following 
keystrokes: 

[-1-/-] [Enter] 


Memory 

(Stack) 


111 

4 ^ 

4 ^ 


Memory 

(Stack) 



Memory 

(Stack) 



(a) After 3rd 
number entered 


(b) After - operation (c) After + operation 
has been performed has been performed 


Figure L5-4. The stack during the first example (values are shown in decimal). 
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This causes our _neg routine to pop the 2-byte value off the top of the 
stack, negate it by subtracting it from 0, and push the result back onto 
the stack. The ensuing -468 jq value is now presented to the display by 
our DISPNUM routine. 

OK, you’re on your own. Run wild and free experimenting with 
different equations to ensure that the calculator functions as planned. 

Enhancing the Calculator Program 

A simple error check 

Let’s start off with a simple suggestion. We know that a math operator 
like “-I-” requires two numbers to be on the top of the stack, for example: 

[1] [2] [3] [Enter] [4] [5] [6] [Enter] [+] [Enter] 

So what will happen if there’s only one number on top of the stack; for 
example, what would occur if we were to start the calculator program 
running and enter the following: 

[1] [2] [3] [Enter] [-I-] [Enter] 

Not surprisingly, the results will be undefined (but they will doubtless 
not be anything we would like to see). Thus, one enhancement you 
might consider would be to modify the program to keep a count of ex¬ 
actly how many numbers are on the stack at any particular time. When a 
unary operator like the “-I-/-” (negate) is selected, the program should 
first check to see that there’s at least one number on the stack. Similarly, 
when a binary operator like “-I-”, or is selected, the program 

should make sure that there are at least two numbers on the stack. 

Activating the Back, CE, and Clear keys 

Another relatively simple enhancement would be to modify the input 
routines to support the use of the “Back,” “CE,” and “Clear” keys. As we 
discussed in Lab 5a, these keys could be used to perform the following 
functions: 

Back: Delete the last digit from the display (clicking this key multiple 
times should delete multiple digits) 

CE: Clear the current data entry (but keep the rest of the calculation as is) 

Clear: Clear the entire calculation and start again 
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Adding binary and hexadecimal input and display 

If we wished to get a tad more sophisticated, we could activate the binary 
(Bin), decimal (Dec), and hexadecimal (Hex) buttons on the keypad. 
This would involve modifying our input and output routines to accept 
and display values in each of these three modes (our core math routines 
would, of course, remain unchanged). 

Changing the usage model 

It won’t take long before you start chaffing at the restrictions imposed 
by our simple usage model. Surely we could modify the input routines 
such that: 

a) We don’t need to press the Enter key after each math function key. 

b) We don’t need to press the Enter key to terminate a number if that 
number is followed by a math function key. 

As we discussed in Chapter 5, implementing these two changes 
alone would make our lives a lot simpler. For example, instead of enter¬ 
ing our original equation using the following keystrokes: 

[1] [2] [3] [Enter] [4] [5] [6] [Enter] [1] [1] [1] [Enter] 

[-] Enter [-I-] [Enter] 

We could now use the following: 

[1] [2] [3] [Enter] [4] [5] [6] [Enter] [1] [1] [1] [-] [+] 

But why stop here? Why not completely redesign the input routines to 
support a standard infix usage model. This would allow us to enter the 
equation as: 

[4] [5] [6] H [1] [1] [1] [+] [1] [2] [3] [=] 

Yes, yes, YES!!! You can do it! So have at it with gusto and abandon 
(and don’t hesitate to let us know how you get on)! 


For your delectation and delight, a whole slew of additional functions, enhancements, and expert- 
ments are presented in Chapter 6. 
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APPENDIX 


A INSTALLING YOUR 
DIY CALCULATOR 


Installing the DIY Calculator on your IBM-compatible PC is very easy, 
as discussed below. Note that you need at least 7 megabytes of free 
space on your hard disk drive; also note that your computer should be 
running Microsoft® Windows® 2000, ME, XP (home or professional), 
or later. 


1) Place the CD-ROM accompanying this book into your computer’s 
CD/DVD drive. For the purpose of these discussions, we will assume 
that the letter associated with this drive is D: (substitute the letter 
used by your system if this is different). 

2) Double-click the My Computer icon on your desktop or use the 
Start > My Computer command to see the drives associated with 
your computer. 

3) Double-click the CD/DVD drive to access the contents of the CD- 
ROM, which will appear as follows: 


/Altium 

/Databook 

/Educators 

/History 

/Xnumbers 

setup.exe 


(This is a folder containing other files) 
(This is a folder containing other files) 
(This is a folder containing other files) 
(This is a folder containing other files) 
(This is a folder containing other files) 
(This is the setup program) 


The contents of the various folders are discussed in more detail in 
Appendix D. 

4) Double-click the setup.exe file to launch the DIY Calculator Setup 
Wizard and initiate the setup process, then click the Next button to 
continue. 

5) For the purpose of these discussions, we will assume that the letter 
associated with your main system drive is C: (substitute the letter 
used by your computer if this is different). By default, the DIY 
Calculator will be installed in a folder called C:\DIY Calculator. 
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It is recommended that you use this default location, but you 
may use the Browse button to select a different target location if you 
wish. When you are ready, click the Next button to continue. 

6) By default, the installation will insert a shortcut called DIY Calcula¬ 
tor in your Start > Programs menu. It is recommended that you use 
this shortcut name, but you may specify a different name if you 
wish. When you are ready, click the Next button to continue. 

7) If you wish to have an icon associated with the DIY Calculator placed 
on your desktop (this is recommended), ensure that the appropriate 
tick-box is selected, and then click the Next button to continue. 

8) At this point, you will be presented with a dialog window showing 
a summary of the installation options you have selected. If you 
agree with these options, click the Install button to complete the 
installation. 

9) The final dialog in the setup wizard allows you to use a tick-box to 
specify whether or not you wish to launch the DIY Calculator at this 
time. Make your selection and then click the Finish button when 
you are ready to continue. 

10) In order to launch the DIY Calculator in the future, you may use the 
Start > Programs > DIY Calculator > DIY Calculator command, or 
you may double-click the DIY Calculator icon on your desktop [this 
assumes that you opted to have this icon placed on your desktop as 
described in point (7) above]. 


Additional Points Worth Noting 

Before you plunge into the fray, there are a couple of points that are well 
worth noting, because these can save you oodles of time when you are 
“up to your ears in alligators” trying to create or debug a program. 

Fonts and terminology used in this book 

• Italics font is used for emphasis, book titles, commands, and path 
and file names. 

• Bold may be used for emphasis. 

• Menu > Command identifies the path used to select a menu 
command. 
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• Courier font is used for program listings and for any text mes¬ 
sages that the software displays on the screen. 

• “Select” means click the left mouse button on the indicated item. 

• “Click-left” (or just “click”) means click the left mouse button on 
the indicated item. 

• “Click-middle” means click the middle mouse button on the 
indicated item. 

• “Click-right” means click the right mouse button on the 
indicated item. 

• “Double-click” means click twice consecutively with the left 
mouse button. 

• “Drag-left” (or just “drag”) means press-and-hold the left mouse 
button on the indicated item, then move the cursor (pointer) to 
the destination and release the button. 

• “Shift-click-left” means press-and-hold the <Shift> key and then 
click the left mouse button on the indicated item. 

• “Ctrl-click-left” means press-and-hold the <Ctrl> key and then 
click the left mouse button on the indicated item. 

Screen resolution 

Although the DIY Calculator can run on a screen resolution as low as 
800 X 600, you will quickly discover that things get a little crowded on 
the display. Thus, it is strongly recommended that you set your resolu¬ 
tion to 1024 X 768 or higher. 

The quickest and easiest way to change your screen resolution is to 
point your mouse cursor at a blank area of your desktop (the back¬ 
ground screen image), away from any applications or icons, click-right 
on the desktop, and then select the Properties item from the ensuing 
pop-up menu. Next, click the Settings tab, change the Screen Resolution 
setting, and click the OK button. 

Arranging the various display utilities 

As soon as you invoke one of the utilities such as the Memory Walker, 
CPU Register, or I/O Ports displays, it is recommended that you imme¬ 
diately drag the display (using its blue title bar) away from the main cal¬ 
culator front panel and locate it in a clear area of the interface. (Note that 
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you can also resize the Memory Walker in a vertical direction so as to 
make more rows of data visible.) 

The reason we suggest this is that, if you inadvertently click the 
front panel when one of the other utilities is “on top,” the front panel 
will “come forward” and may completely obscure the other utility. 

Should this occur, you can drag the calculator front panel around 
the screen with its blue title bar until you see a portion of the hidden dis¬ 
play. Clicking on any part of that display will bring it to the foreground, 
at which point you can drag the display to a clear area of the interface. 

"Losing" and "recovering" the assembler 

This is similar in concept to the previous point. The assembler is an inde¬ 
pendent executable application (program) that is launched from within 
the main DIY Calculator interface. When you click on any part of the 
DIY Calculator interface after you have launched the assembler, then the 
main interface will “come forward” and may completely obscure the as¬ 
sembler. 

Should this occur, you can click the Assembler item in the main 
Windows® taskbar to bring this application to the foreground. 
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ADDRESSING MODES 


Introduction 


The term addressing modes refers to the way in which the CPU deter¬ 
mines or resolves the addresses of any data to be used in the execution of 
its instructions. Different computers can support a wide variety of ad¬ 
dressing modes; the selection of such modes depends both on the com¬ 
puter’s architecture and the whims of the designer. The seven addressing 
modes supported by the DIY Calculator’s CPU are as follows: 

• Implied 

• Immediate 

• Absolute 

• Indexed (or absolute-indexed) 

• Indirect 

• Preindexed indirect 

• Indirect postindexed 


Implied Addressing (imp) 

Implied addressing refers to instructions that comprise only an opcode 
without an operand; for example, the INCA (“increment accumulator”) 
instruction. In this case, any data required by the instruction and the 
destination of any result from the instruction are implied by the instruc¬ 
tion itself (Figure B-1). 

An implied sequence commences when the PC reaches the opcode 
for an implied instruction (a), loads that opcode into the IR (b), and in¬ 
crements the PC (c). Recognizing that this is an implied instruction, the 
CPU executes it and continues on to the next instruction. 

Instructions that use implied addressing are: clrim, deca, decx, 
HALT, INCA, INCX, NOP, POPA, POPSR, PUSHA, PUSHSR, ROLC, RORC, 
RTI, RTS, SETIM, SHL, and SHR. 
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Figure B-1. Implied addressing. 


Standard Immediate Addressing (imm) 

An instruction using standard immediate addressing has one data 
operand byte following the opcode; for example, add $03 (“add $03 to 
the contents of the accumulator) (Figure B-2). 

The sequence commences when the PC reaches the opcode for an 
immediate instruction (a), loads that opcode into the IR (b), and incre¬ 
ments the PC (c). Recognizing that this is an immediate instruction, the 
CPU reads the data byte pointed to by the PC, executes the instruction 
using this data, stores the result in the accumulator (d), and increments 
the PC to look for the next instruction (e). 

Instructions that use standard immediate addressing are: ADD, 
ADDC, AND, CMPA, LDA, OR, SUB, SUBC, and XOR. 

Big Immediate Addressing (imm) 

The big immediate addressing mode is very similar to the standard 
mode, but it refers to instructions that are used to load the 16-bit X, SP, 
and IV registers. An instruction using big immediate addressing has two 
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IR 

ACC 


data operand bytes following the opcode; for example, BLDSP $01C4 
(“load $01C4 into the stack pointer”) (Figure B-3). 

The sequence commences when the PC reaches the opcode for an 
immediate instruction (a), loads that opcode into the IR (b), and incre¬ 
ments the PC (c). Recognizing that this is a big immediate instruction, 
the CPU reads the MS data byte from memory, stores it in the MS byte 
of the target register (d), and increments the PC (e). The CPU then reads 
the LS data byte from memory, stores it in the LS byte of the target regis¬ 
ter (f), and increments the PC to look for the next instruction (g). 

Instructions that use big immediate addressing are: BLDSP, BLDX, 
and BLDiv. 


Standard Absolute Addressing (abs) 

An instruction using standard absolute addressing has two address 
operand bytes following the opcode, and these two bytes are used to 
point to a byte of data (or to a byte in which to store data); for example. 



Figure B-3. Big immediate addressing (using BLDSP as an example). 
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Figure B-4. Standard absolute addressing. 


ADD [ $4B0 6 ] (“add the data stored in location $4B06 to the contents of 
the accumulator) (Figure B-4). 

The sequence commences when the PC reaches the opcode for an 
absolute instruction (a), loads that opcode into the IR (b), and incre¬ 
ments the PC (c). Recognizing that this is a standard absolute instruc¬ 
tion, the CPU reads the MS address byte from memory, stores it in 
the MS byte of one of the temporary PCs (d), and increments the main 
PC (e). The CPU then reads the LS address byte from memory, stores 
it in the LS byte of the temporary PC (f), and increments the main 
PC (g). 
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The main PC is now “put on hold” while the CPU uses the tempo¬ 
rary PC to point to the target address containing the data (h). The CPU 
executes the original instruction using this data, stores the result into the 
accumulator (i), and returns control to the main PC to look for the next 
instruction. 

Instructions that use standard absolute addressing are: add, addc, 
AND, CMPA, LDA, OR, STA, SUB, SUBC, and XOR. Note that, in the case 
of a STA (“store accumulator”), the contents of the accumulator would 
be copied (stored) into the data byte in memory. Also note that the 
jump instructions JMP, JC, JNC, JN, JNN, JO, JNO, JZ, JNZ, and 
JSR can use absolute addressing. In this case, however, the address 
operand bytes point to the target address which will be loaded into the 
main PC. 


Big Absolute Addressing (abs) 

The big absolute addressing mode is very similar to the standard mode, 
but it refers to instructions that affect our 16-bit X, SP, and IV registers. 
An instruction using big absolute addressing has two address operand 
bytes following the opcode, and these two bytes are used to point to a 
pair of bytes from which to load or store data; for example, bldsp 
[ $4B0 6 ] (“load the two bytes of data starting at location $4B06 into the 
stack pointer) (Figure B-5). 

The sequence commences when the PC reaches the opcode for an 
absolute instruction (a), loads that opcode into the IR (b), and incre¬ 
ments the PC (c). Recognizing that this is a big absolute instruction, the 
CPU reads the MS address byte from memory, stores it in the MS byte of 
one of our temporary PCs (d), and increments the main PC (e). The 
CPU then reads the LS address byte from memory, stores it in the LS 
byte of the temporary PC (f), and increments the main PC (g). 

The main PC is now “put on hold” while the CPU uses the tempo¬ 
rary PC to point to the target address containing the MS data byte (h) 
and store it in the MS byte of our target register (i). The CPU then incre¬ 
ments the temporary PC so as to point to the LS data byte (j) and store it 
in the LS byte of our target register (k). The CPU now returns control to 
the main PC to look for the next instruction. 

Remember that the above sequence described a “big load” of one of 
our 16 bit registers (the stack pointer in this example). In the case of a 
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Figure B-5. Big absolute addressing (using BLDSP as an example). 


“big store,” the contents of the 16-bit register in question would be 
copied (stored) into the two data bytes in memory. 

Instructions that use big absolute addressing are: bldsp, bldx, 
BLDIV, BSTSP, and BSTX. 

Indexed Addressing (abs-x) 

An indexed instruction is very similar to its absolute counterpart, in that 
it has two address operand bytes following the opcode. However, these 
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two bytes are added to the contents of the index register (X), and the re¬ 
sult is used to point to a byte of data (or to a byte in which to store data); 
for example, ADD [$4B06,X] (“add the data stored in location ($4B06 -I- 
X) to the contents of the accumulator) (Figure B-6). 

The sequence commences when the PC reaches the opcode for an 
indexed instruction (a), loads that opcode into the IR (b), and incre¬ 
ments the PC (c). Recognizing that this is an indexed instruction, the 
CPU reads the MS address byte from memory, stores it in the MS byte of 
one of our temporary PCs (d), and increments the main PC (e). The 
CPU then reads the LS address byte from memory, stores it in the LS 
byte of the temporary PC (f), and increments the main PC (g). 

The main PC is now “put on hold” while the CPU adds the con¬ 
tents of the temporary PC to the contents of the index register and uses 
the result to point to the target address containing the data (h). The CPU 
now executes the original instruction using this data and stores the result 
into the accumulator (i). Finally, the CPU returns control to the main 
PC to look for the next instruction. (Note that the act of adding the tem¬ 
porary PC to the index register does not affect the contents of the index 
register. Also note that the index register must be loaded with a valid 
value prior to the first indexed instruction.) 



Figure B-6. Indexed addressing. 
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Instructions that use indexed addressing are: add, addc, and, 
CMPA, LDA, OR, STA, SUB, SUBC, and XOR. Note that, in the case of a STA 
(“store accumulator”), the contents of the accumulator would be copied 
(stored) into the data byte in memory. Also note that the jump instruc¬ 
tions JMP and JSR can use indexed addressing; in this case, however, the 
result of adding the contents of the temporary program counter to the 
index register forms the target jump address, which is loaded into the 
main PC. 


Indirect Addressing (ind) 

As for an absolute instruction, an indirect instruction has two address 
operand bytes following the opcode. However, these two bytes do not 
point to the target data themselves, but instead point to the first byte of 
another pair of address bytes, and it is these address bytes that point to 
the data (or to a byte in which to store data). Thus, an indirect instruc¬ 
tion is so-named because it employs a level of indirection. For example, 
consider an LDA [ [ $4B06 ] ] (“load the accumulator with the data 
stored in the location pointed to by the address whose first byte occupies 
location $4B06) (Figure B-7). 

When the PC reaches an indirect opcode (a), the CPU loads that 
opcode into the IR (b), and increments the PC (c). Next, the CPU reads 
the MS address byte from memory, stores it in the MS byte of temporary 
PC A (d), and increments the main PC (e). Next the CPU reads the LS 
address byte from memory, stores it in the LS byte of temporary PC A 
(f), and increments the main PC (g). 

The CPU now employs temporary PC A to read the MS byte of the 
second address (h), store it in the MS byte of temporary PC B (i), and 
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Figure B-7. Indirect addressing. 


increment temporary PC A (j). Next the CPU reads the LS byte of the 
second address, stores it in the LS byte of temporary PC B (k), uses 
temporary PC B to point to the target data (1), and loads this data into 
the accumulator (m). Finally, the CPU returns control to the main PC to 
look for the next instruction. 

Instructions that use indirect addressing are LDA and STA. Note 
that, in the case of a STA (“store accumulator”), the contents of the accu¬ 
mulator would be copied (stored) into the data byte in memory. Also, 
the jump instructions JMP and JSR can use indirect addressing; in this 
case, however, the second address is the target jump address which is 
loaded into the main PC. 

Preindexed Indirect Addressing (x-ind) 

Preindexed indirect addressing is a combination of the indexed and indi¬ 
rect modes. This form of addressing is so-named because the address in 
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the opcode bytes is first added to the contents of the index register, and 
the result points to the first byte of the second address. For example, 
consider an LDA [ [ $4B0 6, X] ] [“load the accumulator with the data 
stored in the location pointed to by the address whose first byte occupies 
location ($4B06 + X)] (Figure B-8). 

When the PC reaches a preindexed indirect opcode (a), the CPU 
loads that opcode into the IR (b), and increments the PC (c). Next, the 
CPU reads the MS address byte from memory, stores it in the MS byte of 
temporary PC A (d), and increments the main PC (e). Now the CPU 
reads the LS address byte from memory, stores it in the LS byte of tem¬ 
porary PC A (f), and increments the main PC (g). 

The CPU now adds the contents of temporary PC A to the contents 
of the index register, uses the result to point to the MS byte of the second 
address (h), and stores this byte in the MS byte of temporary PC B (i). 
The CPU then points to the LS byte of the second address (j), stores it in 
the LS byte of temporary PC B (k), uses temporary PC B to point to the 



Figure B-8. Preindexed indirect addressing. 
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target data (1), and loads this data into the accumulator (m). Finally, the 
CPU returns control to the main PC to look for the next instruction. 

Instructions that use preindexed indirect addressing are lda and 
STA. Note that, in the case of a STA (“store accumulator”), the contents 
of the accumulator would be copied (stored) into the data byte in memo¬ 
ry. Also, the jump instructions JMP and JSR can use this form of ad¬ 
dressing; in this case, however, the address pointed to by the combina¬ 
tion of temporary PC A and the index register is the target jump address 
that is loaded into the main PC. 


Indirect Postindexed Addressing (ind-x) 

Indirect postindexed addressing is similar in concept to preindexed indi¬ 
rect addressing. In this case, however, the address in the opcode bytes 
points to a second address, and it is this second address that is added to 
the contents of the index register to generate the address of the target 
data. For example, consider an LDA [ [ $4B06 ] , X] (Figure B-9). 

When the PC reaches an indirect postindexed opcode (a), the CPU 
loads that opcode into the IR (b), and increments the PC (c). Next, the 
CPU reads the MS address byte from memory, stores it in the MS byte of 
temporary PC A (d), and increments the main PC (e). Now the CPU 
reads the LS address byte from memory, stores it in the LS byte of tem¬ 
porary PC A (f), and increments the main PC (g). 

The CPU uses the contents of temporary PC A to point to the MS 
byte of the second address (h), and stores this byte in the MS byte of 
temporary PC B (i). The CPU then increments temporary PC A to point 
to the LS byte of the second address (j), and stores this byte in the LS 
byte of temporary PC B (k). Now the CPU adds the contents of tempo- 
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Figure B-9. Indirect postindexed addressing. 


rary PC B to the contents of the index register, uses the result to point to 
the target data (1), and loads this data into the accumulator (m). Finally, 
the CPU returns control to the main PC to look for the next instruction. 

Instructions that use indirect postindexed addressing are LDA and 
STA. Note that, in the case of a sta (“store accumulator”), the contents 
of the accumulator would be copied (stored) into the data byte in memo¬ 
ry. Also, the jump instructions JMP and JSR can use this form of ad¬ 
dressing; however, in this case, the address pointed to by the combina¬ 
tion of temporary PC B and the index register is the target jump address 
that is loaded into the main PC. 
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APPENDIX 

C INSTRUCTION 
SET SUMMARY 

Table C-1. Instructions by categories 


Control 

NOP 

No-operation, CPU doesn’t do anything. 


HALT 

Generate internal NOPs until an interrupt occurs. 


SETIM 

Set the interrupt mask flag in the status register. 


CLRIM 

Clear the interrupt mask flag in the status register. 

Arithmetic 

ADD 

Add data in memory to the accumulator. 


ADDC 

Like an ADD, but include contents of the carry flag. 


SUB 

Subtract data in memory from the accumulator. 


SUBC 

Like a SUB, but include contents of the carry flag. 

Logical 

AND 

AND data in memory to the accumulator. 


OR 

OR data in memory to the accumulator. 


XOR 

XOR data in memory to the accumulator. 

Comparison, 

CMPA 

Compare data in memory to the accumulator. 

Shifts, and 

SHL 

Shift the accumulator left 1 bit (arithmetic shift). 

Rotates 

SHR 

Shift the accumulator right 1 bit (arithmetic shift). 


ROLC 

Rotate the accumulator left 1 bit (through carry flag). 


RORC 

Rotate the accumulator right 1 bit (through carry flag). 

Increments and 

INCA 

Increment the accumulator. 

Decrements 

DECA 

Decrement the accumulator. 


INCX 

Increment the index register. 


DECX 

Decrement the index register. 

Loads and 

LDA 

Load data in memory into the accumulator. 

Stores 

STA 

Store data in the accumulator into memory. 


BLDX 

Load data in memory into the index register. 


BSTX 

Store data in the index register into memory. 


BLDSP 

Load data in memory into the stack pointer. 


BSTSP 

Store data in the stack pointer into memory. 


BLDIV 

Load data in memory into the interrupt vector. 

Push and 

PUSHA 

Push the accumulator onto the stack. 

Pop 

POPA 

Pop the accumulator from the stack. 


PUSHSR 

Push the status register onto the stack. 


POPSR 

Pop the status register from the stack. 

lumps 

JMP 

lump to a new memory location. 


JSR 

lump to a subroutine. 


JZ 

lump if the result was zero. 


JNZ 

lump if the result wasn’t zero. 


JN 

lump if the result was negative. (continued) 
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Table C-1. Continued 


Jumps [cont.) 

JNN 

Jump if tlie result wasn’t negative. 


JC 

Jump if tlie result generated a carry. 


INC 

Jump if the result didn’t generate a carry. 


JO 

Jump if the result generated an overflow. 


JNO 

Jump if the result didn’t generate an overflow. 

Returns 

RTS 

Return from a subroutine. 


RTI 

Return from an interrupt. 


Table C-2. Instruction set summary 
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Table C-2. Continued 
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op 
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Legend 

Flags 


Addressing Modes 

op = Opcode 

Z = 

Zero 

imp = 

Implied 

$ = Hexadecimal value 

N = 

Negative 

imm = 

Immediate 

# = Number of bytes 

C = 

Carry 

abs = 

Absolute 

— = No change 

O = 

Overflow 

abs-x = 

Indexed 

> = Magnitude comparison 

<-4 = Shift or rotate thru carry bit 

<I> = Restored by popping status register 

I = 

Interrupt Mask 

ind = 

x-ind = 

ind-x = 

Indirect 

Preindexed indirect 
Indirect postindexed 






1 nnnnin iWiiiiiiiiiii i 11 nni ni ni nnnni ni ni ni i ni ni nni nni nni nnni i ni i nnnnni ni nnni i ni n- 


APPENDIX 



ADDITIONAL RESOURCES 


Resources on the CD-ROM 


When you open up the CD-ROM accompanying this book, you will see a 
number of files and folders (directories) as shown below: 


/Altium 

/Databook 

/Educators 

/History 

/Xnumbers 

setup.exe 


(This is a folder containing other files) 
(This is a folder containing other files) 
(This is a folder containing other files) 
(This is a folder containing other files) 
(This is a folder containing other files) 
(This is the setup program) 


As is discussed in Appendix A, the setup.exe file is used to install the DIY 
Calculator software on your computer. Meanwhile, the contents of the 
remaining folders are as follows: 


/Altium 

The term LiveDesign refers to an integrated digital system design 
methodology that allows you to easily and interactively develop hard¬ 
ware or processor-based applications implemented inside a field-pro¬ 
grammable gate array (FPGA). It does this by allowing you to “see” inside 
the FPGA during development and to communicate in real time with 
FPGA-based virtual instruments and processors running within the 
FPGA-based design. You can develop and debug your design interactive¬ 
ly, without the need for simulation at the system level. 

Altium’s LiveDesign-enabled product range provides a seamlessly 
integrated set of design technologies for capture through to final PCB 
production. Altium’s DXP 2004-based products, including Nexar 2004 
and Pro tel 2004, interface to Altium’s NanoBoard-NBl (a device-inde¬ 
pendent, FPGA-based development board) or to existing third-party de¬ 
velopment boards to provide a complete LiveDesign experience. 

This folder contains a collection of Web-based multimedia presen¬ 
tations. These interactive product demonstrations highlight some of the 
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advanced features in Altium’s Nexar and Protel electronic design soft¬ 
ware solutions, as well as profiling some of Altium’s available hardware 
that supports interactive FPGA development, such as the Nanoboard- 
NBl and a range of LiveDesign Evaluation kits (featuring either a low- 
cost development board or a Universal JTAG Interface). 

In order to view these presentations, use your Web browser to 
launch the top-level HTML (web) page, called Start.html, that you will 
find in this folder. 

/Databook 

For your delectation and delight, the authors have created a tome called 
The Official DIY Calculator Data Book. This magnum opus contains a lot 
of useful information, including a detailed breakdown of the GPU’s 
architecture and an in-depth summary of all aspects of our assembly 
language. 

A complete copy of this databook is to be found as an Adobe® 
Acrobat® PDF file in this folder on the GD-ROM. 


If you don’t already have an Adobe Acrobat Reader installed on your computer, you can download a 
free copy from the www.Adobe.com website. 


/Educators 

Inside this folder, teachers and lecturers will find Adobe Acrobat PDE 
files for each of the labs in the book. These files can be printed out, 
copied, and used as handouts for students. 

furthermore, all of the images used throughout the book (in the 
chapters, labs, and appendices) are included in this folder in the form 
of Microsoft® PowerPoint® presentations. These images may be used 
as is, or they can be employed as the basis to form additional presenta¬ 
tions and handouts so long as appropriate credits are given to 
this tome. 

/History 

Over the course of writing this and other books, the authors have run 
across all sorts of interesting nuggets of history. Over time, these tidbits 
of trivia have grown to almost form a small book in their own right. For 
your amusement, they are gathered together and presented in this folder 
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as a PDF document called The History of Calculators, Computers, and 
Other Stuff. 

/Xnumbers 

As was discussed in Chapter 6, calculator enthusiast James Redin holds 
U.S. Patent 5,623,433 on what he refers to as Structured Numbers or 
Verbal Numerals. 

In this folder, James has kindly provided a suite of web pages that 
include an extremely interesting article (presented as a PDF document) 
on language and numbers, a selection of sample calculators created us¬ 
ing JavaScript that feature James’ Structured Number input techniques, 
and a link to an in-depth History of Calculators located on James’ 
website. 

In order to view this information, use your web browser to launch 
the top-level HTML (Web) page, called Index.html, that you will find in 
this folder. 


Resources on the DIY 
Calculator Website 


The DIY Calculator website at www.DIYCalculator.com contains a 
plethora of additional resources. These include, but are not limited to, 
the following: 

Updates 

As and when we make any changes to the DIY Calculator, we will make 
new versions of the core software available for free download. 

Tools 

The authors have ideas for the creation of a number of support tools 
such as code coverage and profiler applications. As such utilities are cre¬ 
ated (either by the authors or by readers), we will make them available 
via the DIY Calculator website. 

File Formats 

In order to facilitate the creation of additional utilities, the formats of the 
various files that are input and output by the DIY Calculator (and its 
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support tools such as the assembler) are documented on the DIY 
Calculator website. 

Articles 

The DIY Calculator website features a number of articles on a variety of 
topics. Some examples are as follows. 

Alternative Architectures. The virtual microprocessor featured in the DIY 
Calculator contains a single accumulator, an index register, and a stack 
pointer. Over the years, computer architects have experimented with a 
variety of different architectures, such as multiple accumulators, addi¬ 
tional general-purpose registers, and so forth. This article summarizes 
the various architectures used in some of the early microprocessors. 

Floating-point. The math routines presented in this book are designed to 
work only with integer values. In reality, of course, this is very limiting, 
because it means that we can’t represent real numbers like 3.142. This ar¬ 
ticle introduces the concepts of floating-point representations and de¬ 
fines a simple binary floating-point format. Also described are the cre¬ 
ation of associated floating-point subroutines for the fundamental math 
operations (-t-, -, *, and /). 

Binary coded decimal (BCD). Many folks belittle the BCD format, in 
which each digit in a decimal number is represented by four binary bits. 
However, there are a lot of interesting aspects to this approach of which 
one should at least be aware. This article introduces core BCD concepts 
and describes the creation of associated BCD subroutines for the funda¬ 
mental math operations (-I-, -, *, and /). 

Subroutines 

Over time, the authors (and, we hope, some of our readers) will create 
additional integer, floating-point, and BCD-based subroutines. These 
routines will be made available via the DIY Calculator website for other 
readers to download, peruse, and ponder. 

Further Reading 

The various facts and tidbits of trivia with which this tome is festooned 
were gleaned from a wide variety of sources. In many cases, different ref- 
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erences present contradictory information, so one has to weigh the vari¬ 
ous offerings in the hope of achieving something of a reasonable consen¬ 
sus. Taking all of this into account, the authors have found the following 
sources to be of particular use and interest. 

Books 

Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), 
Second Edition, by Clive “Max” Maxfield, Newnes ISBN: 0-7506- 
7543-8. A highly understandable introduction as to how transistors can 
be used to implement simple logic gates, how these gates can be com¬ 
bined to form more complex functions, and how silicon chips are 
fabricated. 

CODE (The Hidden Language of Computer Hardware and Software), by 
Charles Petzold, Microsoft Press, ISBN: 0-7356-1131-9. A nicely present¬ 
ed, easy-to-understand introduction to the ways in which computers 
represent and manipulate data. 

Dictionary of Word Origins, by John Ayto, Arcade, ISBN: 1-55970-214-1. 
Described as “. . . perhaps the best inexpensive etymological dictionary 
available today.. .,” this useful tome offers insights into the origins and 
histories of 8000-plus English words and the connections to their non- 
English ancestors. 

Dimboxes, Epopts, and other Quidams, by David Grambs, Workman, 
ISBN: 0-89480-155-4. A compendium of words that can be used to de¬ 
scribe life’s indescribable people, from the most innocuous creep at the 
office party (“pigwidgeon”) to the motormouth who tyrannizes the car 
pool (“blatteroon”). 

Latin Lor All Occasions, by Henry Beard, Villark, ISBN: 0-394-58660-3. If 
you have ever found yourself in the position of needing to know the 
Latin for such everyday phrases as: “God, look at the time! My wife will 
kill me!” or “Darn, there goes my beeper!” or even “I have a catapult. 
Give me all the money or I will fling an enormous rock at your head,” 
then this is the book for you! 

The New Hacker’s Dictionary, Third Edition, by Eric Raymond, MIT 
Press, ISBN: 0-262-68092-0. A great source for tracking down the origin 
and historical development of computer jargon and terms. 
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The Timetables of Science, by Alexander Hellemans and Bryan Bunch, Si¬ 
mon & Schuster, ISBN: 0-671-73328-1. An incredibly useful quick-refer¬ 
ence chronology of the most important people and events in the history 
of science (astronomy, biology, chemistry, earth science, mathematics, 
medicine, physics, and technology) from the earliest verifiable manufac¬ 
ture of stone tools to the present time. 

The Universal History of Computing, by Georges Ifrah, Wiley, ISBN: 0- 
471-44147-3. In this well-researched tome, the author traces the concep¬ 
tual, scientific, and technical achievements that made modern comput¬ 
ing a reality; from the abacus to the quantum computer, and from the 
invention of the binary number system three hundred years ago to the 
recent discovery of “surreal numbers.” 

The Universal History of Numbers, by Georges Ifrah, Wiley, ISBN: 0-471- 
39340-1. Not an easy read by any stretch of the imagination, but this 
book is an absolute treasure-trove of information. Described as “.. . a 
mind-boggling and enriching experience . . .” by the British newspaper 
The Guardian. 

Zero to Lazy Eight: The Romance of Numbers, by Alexander Humez, 
Nicholas Humez, and Joseph Maguire, Touchstone, ISBN: 0-671-74281- 
7. Did you ever wonder why “a stitch in time saves nine” and not, say, 
four? Or why the number seven is considered to be so lucky? Or to what 
number the word “googol” refers? Well, all is explained in this delightful¬ 
ly wacky and entertaining offering. 

Websites 

www.Ask.com. Of all of the search engines available, this “Ask Jeeves” 
website almost invariably proves to be particularly useful when it comes 
to finding simple explanations for tricky concepts. 

www.Dictionary.com. In addition to coming into play for simply check¬ 
ing the spelling of a word, this is an incredibly useful site for tracking 
down the origins of words, different ways of using the same word, and 
alternative words by means of its Thesaurus function. 

http://members.aol.com/jeff570/mathsym.html. Maintained by Jeff Miller, 
a teacher at Gulf High School in New Port Richey, Florida, these pages 
provide a wealth of information as to the earliest usage of various mathe¬ 
matical symbols. 
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We need your help! 

The great thing about computer-based math is that there are a myriad 
ways of doing everything. So if you are aware of any interesting algo¬ 
rithms for any applicable math routines, then please feel free to share 
these with us and we’ll make them available to other readers by means of 
the DIY Calculator website (our contact details are to be found on the 
website at www.DIYCalculator.com). 

Furthermore, if you are an educator and come up with your own 
laboratories, lesson plans, and tests (in the form of question-and-answer 
or multiple-choice papers), we would very much like to make these avail¬ 
able to other lecturers via our website (except for the answers to any 
questions, of course, which we would make available via email only to 
teachers and not to their students <grin>). 
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Index 


. (button / code / key), 187 
■BYTE (directive), 203 
■END (directive), 164, 165 
•EQU (directive), 170 
•ORG (directive), 164, 165 
± (or +/-), 125 
± (button / code / key), 186 
+ (button / code / key), 187 
+ (origin of symbol), 74 

- (button / code / key), 187 

- (origin of symbol), 88 
X (origin of symbol), 107 

• (use in multiplication), 107 
^ (button / code / key), 187 
^ (qualifier for .BYTE), 246 
^ (use in multiplication), 107 
(origin of symbol), 115, 116 
/ (button / code / key), 187 
/ (use in division), 115, 116 
: (use in division), 115, 116 
= (as an assignment), 183 
= (button / code / key), 187 
= (origin of symbol), 78 
== (logical equivalence), 183 
< (origin of symbol), 94 
> (origin of symbol), 94 
? (or <=), 94 
? (or >=), 94 
? (or !=), 94 

! (inversion / negation), 183 
! (factorial), 64, 187, 273 
!= (not equal to), 183, 238 
« (shift left), 106, 107 
^ (exponent), 129 
TT (Pi), 145 

TT (button / code / key), 187 
00 (infinity), 70, 119 
( (button / code / key), 187 
) (button / code / key), 187 
( ) (operation ordering), 129-131, 
140 


[ ] (memory addressing), 165 

$ (as a hexadecimal prefix), 20 
% (as a binary prefix), 13 
# (comment), 165 
: (label terminator), 172 

1-bit adder, 74 

1/x (button / code / key), 187 
4-bit division, 351-359 
4-bit multiplication, 333-339 
8-bit adder, 75 
16-bit addition 
signed, 327-329 
unsigned, 299-309 
16-bit division, 360-371 
16-bit multiplication, 339-349 
16-bit subtraction 
signed, 329-332 
unsigned, 311-315 
-32,768, testing for, 323-326 

A 

absolute addressing, 162, 242 
big absolute, 421 
standard, 419 
accumulator (ACC), 159 
pushing onto stack, 48 
after call to subroutine, 58 
before call to subroutine, 57 
popping off stack, 49 
ACK (acknowledge) code, 176 
AD (Ano Domini), 9 
_ADD (subroutine) 
signed 16-bit, 327-329 
unsigned 16-bit, 299-309 
ADD (instruction), 76 
carry flag, effect on, 78 
ADDC (instruction), 81 
carry flag, effect on, 81 
addend, 72 


adder 

1-bit full adder, 74 
8-bit adder, 75 
ripple carry adder, 76 
addition, adding 
binary numbers 
signed, 101 
unsigned, 71, 72 
decimal numbers, 72 
multibyte additions, 79 
symbol (+), 74 
address 
bus, 26 
labels, 180 

cross-reference table, 207 
memory, 28 
return address, 54 
space, 28 

addresses, memory, 28 
addressing modes 

absolute addressing, 162, 242 
big absolute, 421 
standard, 419 

immediate addressing, 161, 240 
big immediate, 418 
standard, 418 

implied addressing, 179, 241, 417 
indexed, 204, 422 
indirect, 424 

postindexed, 427 
preindexed, 408, 425 
advanced DAL, 131, 140 
Alice in Wonderland, 69 
alligators, up to your ears in, 414 
alphanumeric characters, 175 
Altium Ltd., 151, 433 
LiveDesign, 433 
NanoBoard, 433 
Nexar 2004, 433 
Protel 2004, 433 
ALU (arithmetic logic unit), 89 
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analog computers, 15 
AND 

instruction, 37 
logic gate, 36 
Andy Rooney, 23 
Ano Domini (AD), 9 
Antikythera calculator, 3 
Antiquity, 4, 74 
arbitrary-precision BCD 
fixed-point, 146 
integers, 146 

arbitrary-sized integers, 141 
Archimedes, 1 
arithmetic 

logic unit (ALU), 89 
shifts, 39 

coercing into logical, 41 
in division, 114 
Arithmetic Machine, 4 
array of characters, 202 
ASCII, 175, 176 
assembler, 182 

cross-assembler, 150 
assembling a program, 166 
assembly language, 162 
comments, 165 
directives 
.BYTE, 203 
.END, 164, 165 
.EQU, 170 
.ORG, 164, 165 
labels 

address labels, 180 
constant labels, 169 
cross-reference tables, 206, 207 
rules, 171 

see also instructions 
augend, 72 
Aunt Sally, 130 


B 

Back 

button / code / key, 186, 377, 411 
code for display, 176 
Bacon, Francis, 135 
band, marching, 24 
bang character (“!”), 183 
bankers’ rounding, 118, 357 


base 

base-8, 17 
base-10, 9 
base-12, 8 
base-20, 8 

of exponential number, 10 
BC (Before Christ), 9 
BCD (binary coded decimal), 145 
arbitrary-precision 
fixed-point, 146 
integer, 146 
fixed-point, 146 
fixed-precision 
fixed-point, 146 
integer, 146 
floating-point, 147 
structured (verbal), 146 
BCE (Before Common Era), 9 
be afraid, be very afraid, 190 
Bebop to the Boolean Boogie, 74 
BEDMAS, 130 
Before 

Christ (BC), 9 
Common Era (BCE), 9 
Being and Nothingness, ix 
Bell code (display), 176 
Bells and whistles 
beyond our wildest dreams, 403 
big 

addressing modes 
big absolute, 421 
big immediate, 418 
elephants, 130 
spring, 46 
bigit, 13 

Bin (button / code / key), 187 
binary 
adder 

1-bit full adder, 74 
8-bit adder, 75 
addition 

ADD (instruction), 76 
ADDC (instruction), 81 
multibyte additions, 79 
signed numbers, 101 
unsigned numbers, 71, 72 
bit, 13 
byte, 13 

coded decimal (BCD), 145 


arbitrary-precision 
fixed-point, 146 
integer, 146 
fixed-point, 146 
fixed-precision 
fixed-point, 146 
integer, 146 
floating-point, 147 
structured (verbal), 146 
counting in, 13 
digits and column weights, 12 
division 

4-bit division, 351-359 
16-bit division, 360-371 
by shifting right, 113 
long division, 115 
rounding, 117-119 
floating-point, 145 
multiplication 

4-bit multiplication, 333-339 
16-bit multiplication, 339-349 
by shifting left, 105 
shift-and-add, 109 
times table, 14 
nybble, 13 

operators (-H, -, *, /), 125 
signed binary numbers, 98, 99 
sign-magnitude, 96, 97 
subtraction 

multibyte subtractions, 94 
ones complement, 86 
signed numbers, 102 
SUB (instruction), 91 
SUBC (instruction), 94 
twos complement, 87 
unsigned numbers, 82, 86, 87 
subtractor, 88 
times table, 14 
to hexadecimal, 20 
unsigned binary numbers, 16, 

70 

binit, 13 
bit, 13 

bit-wise fashion, 37 
Blaise Pascal, 4 
BLDSP (instruction), 47 
BLDX (instruction), 46 
boot, booting, 25 
bootstraps, 25 
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borrow 

American borrow, 82 
English borrow, 83 
flag, 91 

borrow-not (borrow-out-not), 92 
box, boxes 

in warehouse, 46 
memory locations, visualizing, 26 
of breakfast cereal, 5 
Pandora’s box, 66 
brackets, 130 
brain, squeezing, 182 
breakfast cereal, boxes of, 5 
breakpoints, using, 209 
BSTSP (instruction), 47 
BSTX (instruction), 46 
bus / buses / busses, 16, 26 
address bus, 26 
control bus, 26 
data bus, 16, 26 
buttons 

keypad buttons, 186, 187 
On/Off button, 166, 173 
Reset button, 173, 209 
Run button, 166, 173, 209 
Step button, 173, 209 
Buzz of excitement, 406 
byte, 13 

Byzantine Empire, 4 
C 

C (carry) status bit, 177 
effect of 
ADD, 78 
ADDC, 81 
CMPA, 62 

ROLC, RORC,41,42 
SHE, SHR, 39, 40, 196 
SUB, 91 
SUBC, 95 
JC instruction, 191 
JNC instruction, 191 
C (programming language), 106 
cafeteria, 46 
Calculating Clock, 4 
calculator 

definition of, 29 
framework program, 375-382 
history, 434 


calculators 

Antikythera Calculator, 3 
Arithmetic Machine, 4 
Calculating Clock, 4 
DIY Calculator, 30 
history, 434 
Pascaline, 4 
Pocketronic, 5 
Step Reckoner, 4 
Cannon, 5 

capriciously cunning, 409 
Captain Edward A. Murphy, 197 
cardinal numbers, 70 
Cards 

Christmas cards, 3 
Summer-solstice cards, 3 
Carroll, Lewis, 69 
carry (C) status bit, 177 
effect of 
ADD, 78 
ADDC, 81 
CMPA, 62 

ROLC, RORC, 41, 42 
SHL, SHR, 39, 40, 196 
SUB, 91 
SUBC, 95 
JC instruction, 191 
JNC instruction, 191 
carry-in (cin) signal, 74 
carry-out (cout) signal, 74 
CE (button / code / key), 186, 377, 
411 

CE (Common Era), 9 
central processing unit (CPU), 24 
accumulator (ACC), 159 
pushing onto stack, 48 
after call to subroutine, 58 
before call to subroutine, 57 
popping off stack, 49 
arithmetic logic unit (ALU), 89 
clock signal, 24 
index register (X), 45, 202, 
245-254 

accessing contents, 249-252 
as a counter, 252-254 
instruction register (IR), 240 
program counter (PC), 44, 
237-243 

register display, 211, 212 


reset 

mode, 160 
power-on reset, 25 
signal, 24 

stack pointer (SP), 46, 47, 255-259 
status bits / flags, 177, 211 
status register (SR), 177 
bits / flags, 177 
popping off stack, 50 
pushing onto stack, 50 
character 

array of characters, 202 
codes (ASCII), 175, 176 
string of characters, 202 
Charles Leonard Hamblin, 132 
Charlie Brown, 99 
chastised soundly, 66 
chieftain, warrior, 3 
CHK2NEG (subroutine), 324-326, 
388 

chopping (rounding), 107 
Christmas card, 3 
cin (carry-in) signal, 74 
Clavis Mathematicae, 107 
Clear (button / code / key), 186, 377, 
411 

clearing bits (using AND), 37 
clock signal, 24 
clothing, rending of, 73 
Clr (clear) code (display), 176 
CMPA (instruction), 62, 190 
carry flag, effect on, 62, 191 
zero flag, effect on, 191 
code / codes 

Back code (display), 176 
Bell code (display), 176 
Clr (clear) code (display), 176 
condition codes, 177 
coverage / profiler, 147 
keypad codes, 186, 187 
machine code, 161 
opcodes, 161 
operation codes, 161 
self-modifying code, 64 
source code / file, 164, 206 
coin tossing, 119 
commands (assembler) 

File > Assemble, 166 
Insert > Insert File , 308 
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commands (assembler) (continued) 
Insert > Insert String, 217 
Window > View List File, 205 
Window > View Source File, 216 
commands (main window) 

Display > CPU Registers, 211 
Display > I/O Ports, 213 
Display > Memory Walker, 207 
Display > Message System, 215 
Memory > Load RAM, 32, 166 
Memory > Purge RAM, 191 
Setup > System Clock, 197 
Tools > Assembler, 164 
comments, 165 

comment character (“#”), 165 
Common Era (CE), 9 
compiler, 106 

complement techniques, 82 

diminished radix complement, 84 
nines complement, 84 
ones complement, 86 
radix complement, 84 
tens complement, 84, 85 
twos complement, 87, 100 
computer 

definition of, 24 
history of 434 
weenies, 225 
condition codes, 177 
constant labels, 169 

cross-reference table, 206, 207 
contemptuously sneering, 73 
control bus, 26 
Cos (button / code / key), 187 
cosine, 187 
counting 

from zero, 71 
goats, 9 
in binary, 13 
in decimal, 11 
in hexadecimal, 18 
numbers, 70 

cout (carry-out) signal, 74 
CPU (central processing unit), 24 
accumulator (ACC), 159 
popping off stack, 49 
pushing onto stack, 48 
after call to subroutine, 58 
before call to subroutine, 57 


arithmetic logic unit (ALU), 89 

clock signal, 24 

index register (X), 45, 202, 

245-254 

accessing contents, 249-252 
as a counter, 252-254 
instruction register (IR), 240 
program counter (PC), 44, 

237-243 

register display, 211, 212 
reset 

mode, 160 
power-on reset, 25 
signal, 24 

stack pointer (SP), 46, 47, 255-259 
status bits / flags, 177, 211 
status register (SR), 177 
bits / flags, 177 
popping off stack, 50 
pushing onto stack, 50 
CR (carriage return) code, 176 
creating a program, 164 
cross-assembler, 150 
cross-reference tables, 206, 207 
cube, 11, 187 
perfect cube, 11 
cunning 
games, 62 

tricks and ploys, 334, 352, 390, 396 

D 

DAL (direct algebraic logic), 130, 139 
advanced DAL, 131, 140 
Dark Ages, the, 4 
data 

bus, 16, 26 

definitions of 16, 25, 227 
global data, 227 
local data, 227 

debugging a program, 201-216 
debugging tools 

CPU Register display, 211, 212 
I/O Ports display, 212-214,, 
Memory Walker display, 
207-211 

using breakpoints, 209 
Message System display, 214-216 
Dec (button / code / key), 187 
DECA (instruction), 179 


decimal numbers 
adding, 72 
dividing, 114, 115 
multiplying, 108 
subtracting, 82 
decimal number system, 8 
counting in, 11 
digits and column weights, 10 
DECX (instruction), 46, 204 
deja vu, 5 
diagnostic tools 

CPU Register display, 211, 212 
I/O Ports display, 212-214,, 
Memory Walker display, 
207-211 

using breakpoints, 209 
Message System display, 214-216 
diamonds (flowchart decisions), 179 
difference (result from subtraction), 
83 

digital computers, 15 
digits 

binary digits, 12 
decimal digits, 10 
fingers and toes, 8 
hexadecimal digits, 18, 19 
dilly-dallying, 179 
diminished radix complement, 84 
direct algebraic logic (DAL), 130, 139 
directives 
.BYTE, 203 
.END, 164, 165 
.EQU, 170 
.ORG, 164, 165 

DISPERR (subroutine), 292-294, 
386-387 

Display > CPU Registers, 211 
Display > I/O Ports, 213 
Display > Memory Walker, 207 
Display > Message System, 215 
DISPNUM (subroutine) 
decimal, 395-403 
hexadecimal, 288-292 
dividend, 113 
division, dividing 
4-bit values, 351-359 
16-bit values, 360-371 
binary numbers (signed) 
by shifting right, 113 
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long division, 116 
decimal numbers, 114, 115 
non-restoring algorithm, 354 
restoring algorithm, 354 
rounding, 117-119 
sign correction, 117, 359, 369 
symbols (/,;, etc.), 115, 116 
divisor, 113 
DIY Calculator, 30 
building a real one, 148 
installing, 413 

loading / running programs, 166 
website, 435 
Don’t Panic!, 342 
Douglas Adams, 349 
dozen (meaning 12), 8 
drum beat, 24 
dumb device, 30 
dummy functions, 378 

E 

eclipses, predicting, 3 
editing a program, 164 
educators (resources), 434 
electrical potential, 15 
electronic computers, 15 
equals symbol (“=”), 78 
end-around-carry, 84, 86 
Enter (button / code / key), 186, 377 
EOT (end of transmission) code, 176 
Ernest Renan, 1 
error checking, 175 
parity checking, 175 
even parity, 175 
excruciating detail, 74 
excruciatingly boring, 162 
Exp (button / code / key), 187 
exponential form, 10 
base, 10 
exponent, 10 

exponents (powers), 10, 130 
eyes watering, 182 

E 

factor, 113 

factorials, 64, 187, 273 
false (logic value), 36 
fashion, slaves to, 2 
fearsome warriors, 2 


feeling frisky, 184 
feminine, 6 

field-programmable gate array 
(FPGA), 150 
File > Assemble, 166 
file 

list file, 205 
skeleton file, 221 
source file, 161, 206 
fingers and toes, counting on, 8 
fire, ordeal by, 30 
fixed-point BCD, 146 
fixed-precision BCD 
fixed-point, 146 
integer, 146 
floating-point 
BCD, 147 
binary, 145 
flowchart, 160 

actions (rectangles), 161 
decisions (diamonds), 179 
FMULT (subroutine), 273 
forward referencing, 172, 181 
FPGA (field-programmable gate 
array), 150 

fractions (indicating with “:”), 115 

Francis Bacon, 135 

frantic blur, 197 

front panel, 162 

F-S (button / code / key), 187 

fumble and stumble, 30 

further reading, 436 

G 

gates, logic, 15, 36 
AND, OR, XOR, 36 
gemowe lines, 78 
German Algebra, 107, 115 
GETNUM (subroutine) 
decimal, 389-394 
hexadecimal, 280-288 
GETSTUFF (subroutine), 383-386 
giggles and grins, 349 
global data, 227 
gnashing of teeth, 73 
goats 

counting goats, 9 
negative goats, 9 
zero goats, 9 


Goldilocks and the three bears, 115 
Gottfried von Leibniz, 4, 23, 107, 115 
grab a friend, 184 
greater-than-or-equal-to (>=), 94 
greater-than symbol (>), 94 
Greece, ancient, 3 
gross (meaning 144), 8 
gusto and abandon, 412 

H 

Hamblin, Charles Leonard, 132 
Hamlet, 7, 35 
hardware multiplier, 110 
Harriot, Thomas, 94 
Hellenistic Period, 3 
Hello 

Sailor, 216 
World, 175, 201 
Hewlett Packard, 132 
Hex (button / code / key), 187 
hexadecimal number system, 16 
counting in, 18 
digits 

and column weights, 18 
sixteen digits, 18 
mapping to binary, 20 
sixteen digits, 19 

history (calculators, computers, etc.), 

434 

Hitchhiker’s Guide to the Galaxy, 349 
hot spot, 148 

HP (Hewlett Packard), 132 
huge dollops, 2 
Huntsville, Alabama, USA, 2 
hydraulic computers, 15 

I 

I (interrupt mask) status bit, 177 
IC (integrated circuit), 149 
invention of, 4 

immediate addressing, 161, 240 
big immediate, 418 
standard, 418 

implied addressing, 179, 241, 417 
INCA (instruction), 179 
INCX (instruction), 46, 204 
indexed addressing, 204, 422 
index register (X), 45, 202, 245-254 
accessing contents, 249-252 
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index register (X) (continued) 
as a counter, 252-254 
indexed addressing, 204, 422 
indirect addressing, 424 
postindexed, 427 
preindexed, 408, 425 
India, 4 

indirect addressing, 424 
postindexed, 427 
preindexed, 408, 425 
infinity, 70, 119 
infix notation, 125, 126 
input/output (I/O) ports, 24 
Insert > Insert File, 308 
Insert > Insert String, 217 
instructions 

ADD (add without carry), 76 
ADDC (add with carry), 81 
AND (logical), 37 
BLDSP (load stack pointer), 47 
BLDX (load index register), 46, 
204 

BSTSP (store stack pointer), 47 
BSTX (store index register), 46 
CMPA (compare accumulator), 
62, 190 

DECA (decrement accumulator), 
179 

DECX (decrement index reg), 46, 
204 

INCA (increment accumulator), 
179 

INCX (increment index reg), 46, 
204 

JC (jump if carry), 191 
JMP (unconditional jump), 165 
JN (jump if negative), 190 
JNC (jump if not carry), 191 
JNN (jump if not negative), 190 
JNO (jump if not overflow), 105 
JNZ (jump if not zero), 180, 183 
JO (jump if overflow), 105 
JSR (jump to subroutine), 53 
JZ (jump if zero), 180, 182 
EDA (load accumulator), 165 
NOP (no operation), 256 
NOT (logical), 38 
OR (logical), 37 
POPA (pop accumulator), 49 


POPSR (pop status register), 50 
PUSHA (push accumulator), 48 
PUSHSR (push status register), 

50 

ROLC (rotate left), 41, 42, 43 
RORC (rotate right), 41, 42, 43 
RTS (return from subroutine), 54, 
56, SHE (shift left), 38-40 
SHR (shift right), 38-40, 195 
STA (store accumulator), 165 
SUB (subtract without carry), 91 
SUBB (subtract with borrow), 94 
SUBC (subtract with carry), 94 
instruction 

register (IR), 240 
set, 161 

summary, 429-431 
integers, 70 

arbitrarily-sized integers, 141 
BCD representations, 145 
bigger integers, 141 
dynamically-sized integers, 141 
integrated circuit (IC), 149 
invention of, 4 

Interrupt mask (I) status bit, 177 
I/O (input/output) ports, 24 
I/O Ports display, 212-214 
IR (instruction register), 240 

J 

James Redin, 144, 435 
Jan Eukasiewicz, 132 
JC (instruction), 191 
Jean-Paul Sartre, ix 
jellybean devices, 149 
JN (instruction), 190 
JNC (instruction), 191 
JNN (instruction), 190 
JNO (instruction), 105 
JNZ (instruction), 180, 183 
JO (instruction), 105 
Johann 

Rahn, 107, 115 
Rhonius, 107 
Widmann, 78, 88 
John 

Napier, 107 
Wilder Tukey, 13 
JSR (instruction), 53 


judicious tweaking, 148 
JZ (instruction), 180, 182 

K 

Keep it simple, stupid!, 383 
keypad 

buttons / codes, 186, 187 
reading from keypad, 185, 188 
Key to Mathematics, 107 
KISS principle, 383 

E 

labels 

address labels, 180 
constant labels, 169 
cross-reference tables, 206, 207 
rules, 171 

last-in, first-out (LIFO), 47 
latch, 185 

EDA (instruction), 165 
least-significant 

bit (ESB), 16, 71, 159 
byte (ESB), 44 
lecturers (resources), 434 
Eeibniz, Gottfried von, 4, 23, 107, 115 
less-than-or-equal-to (<=), 94 
less-than symbol (<), 94 
lethargic snail, 197 
Eewis Carroll, 69 
EF (line feed) code, 176 
Eife, the Universe, and Everything, 
349 

EIFO (last-in, first-out), 47 
light-emitting diodes (EEDs) 
on front panel, 173 
writing to them, 193 
list file, 205 

body of file, 205 
cross-reference tables, 206, 207 
EiveDesign, 433 
loading a program, 166 
local data, 227 
locations (memory), 27 
locking up, 210 
Eog (button / code / key), 187 
logarithm / logarithms, 107, 187 
logical 

instructions, 36, 37 
AND, OR, XOR, 37 
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NOT, 38 
shifts, 40 

logic gates, 15, 36 
loops / looping, 179 
nested loops, 188 
lowercase, 172 
LSB 

least-significant bit, 16, 71, 159 
least-significant byte, 44 
Lukasiewicz, Jan, 132 

M 

machine code, 161 
macroactions, 215 
madness, reason behind the, 100 
Mae West, 123 

main display, writing to, 173, 178 
map, memory, 51, 157 
mapping 

binary to hexadecimal, 20 
hexadecimal to binary, 20 
marching band, 24 
Mars, the planet, ix 
Martians, ix 
masculine, 6 

masking bits (using AND and OR), 
37 

McCloskey, Robert, 183 
mechanical computers, 15 
memory 

addresses, 28 
address space, 28 
LIFO process, 47 
locations, 27 
map, 51, 157 
purging memory, 191 
RAM, 24, 25, 27 
ROM, 24, 25, 27 
RWM, 26 

scrambling memory, 181 
Walker display, 207-211 
using breakpoints, 209 
words, 28 

Memory > Load RAM, 32, 166 
Memory > Purge RAM, 191 
Memory Walker display, 207-211 
using breakpoints, 209 
Message System display, 214-216 
mice and snails, 130 


Mickey Mouse, 69 

Microactions, 215 

microcontroller, 149 

microprocessor, 149 

Middle Ages, 4, 74 

minuend, 83 

minus, 88 

mists of time, 130 

mnemonic, 165 

Mod (button / code / key), 187 

modes 

addressing modes 
absolute, 162, 242 
big absolute, 421 
standard, 419 
immediate, 161, 240 
big immediate, 418 
standard, 418 
implied, 179, 241, 417 
indexed, 204, 422 
indirect, 424 

postindexed, 427 
preindexed, 408, 425 
calculator modes 
reset mode, 209 
run mode, 209 
step mode, 209 

modifying the system clock, 197 
monitor program, 158, 160 
most-significant 

bit (MSB), 16, 71, 159 
byte (MSB), 44 
MSB 

most-significant bit, 16, 71, 159 
most-significant byte, 44 
_MULT (subroutine), 339-349 
multiplicand, 106 
multiplication, multiplying 
4-bit values, 333-339 
16-bit values, 339-349 
binary numbers 
by shifting left, 105 
shift-and-add, 109 
decimal numbers 
shift-and-add, 108 
hardware multiplier, 110 
sign correction, 112, 339, 346 
sign of result, 112 
symbols (x, *, etc.), 107 


multiplier, 106 

hardware multiplier, 110 
Murphy, Captain Edward A., 197 
Murphy’s Law, 197 
mutually recursive subroutines, 64 
My Little Chickadee, 123 

N 

N (negative) status bit, 177, 190 
JN instruction, 190 
JNN instruction, 190 
n! (button / code / key), 187 
NanoBoard, 151, 433 
Napier, John, 107 
natural numbers, 70 
naughty, very, 66 
_NEG (subroutine), 317-321 
negative 
goats, 9 

numbers, concept of, 9 
status bit (N), 177, 190 
JN instruction, 190 
JNN instruction, 190 
nested 
loops, 188 

subroutines, 63, 264-265, 402 
Nexar2004, 151,433 
nibble, 13 

nines complement, 84 
non-restoring division algorithm, 354 
NOP (instruction), 256 
NOT (instruction), 38 
notations 

infix notation, 125, 126 
Polish notation, 132 
postfix notation, 126, 132 
the stack, 127 
prefix notation, 126, 132 
reverse Polish notation, 132, 409 
scalar notation, 76, 160 
Smith notation, 132 
vector notation, 75, 159 
not-equal (!=), 94 
_NOTYET (subroutine), 387 
NSWUT, 132 
NUL / NULL (code), 204 
numbers 

cardinal numbers, 70 
counting numbers, 70 
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numbers (continued) 
integers, 70 
natural numbers, 70 
ordinal numbers, 70 
positive integers, 70 
whole numbers, 70 
number sign (“#”), 165 
number systems 
base-8, 17 
base-10, 9 
base-12, 8 
base-20, 8 
binary, 12 
decimal, 8 
hexadecimal, 16 
octal, 17 
place-value, 3, 9 
radix-10, 9 
Roman numerals, 9 
nybble, 13 

O 

O (overflow) status bit, 103, 104, 
177 

JNO instruction, 105 
JO instruction, 105 
obelus, 115 
octal, 17 
odd parity, 175 
ones complement, 86 
On/Off button, 166, 173 
opcode, 161 
operand, 161 
operation codes, 161 
operations, order of, 129 
operators 

binary (+, -, *, /), 125 
precedence of operators, 129 
unary (+/-), 125 

OR 

instruction, 37 
logic gate, 36 
ordeal by fire, 30 
order of operations, 129 
ordinal numbers, 70 
Oughtred, William, 107 
overflow, 100 

stack overflow, 52 
status bit (O), 103, 104, 177 


JNO instruction, 105 
JO instruction, 105 

P 

palindrome, 272 
Pandora’s box, 66 
parameters and subroutines, 59 
parentheses, 129-131, 140 
parity checking, 175 
partial products 

binary multiplication, 109 
decimal multiplication, 108 
Pascal, Blaise, 4 
Pascaline, 4 

PC (program counter), 44, 237-243 
pear-shaped, things going, 25 
pebbles, 8 
PEMDAS, 130 
perfect 
cube, 11 
square, 11 
Pi (it), 145 

button / code / key, 187 
PIC (microcontroller), 151 
pile of serving plates, 46 
place-value number systems, 3, 9 
Planet Mars, ix 
pneumatic computers, 15 
Pocketronic, 5 
Polish notation, 132 
POPA (instruction), 49 
popping 

accumulator off stack, 49 
status register off stack, 50 
POPSR (instruction), 50 
positive integers, 70 
postfix notation, 126, 132 
the stack, 127 

postindexed indirect addressing, 

427 

pound sign (“#”), 165 
power-on reset, 25 
precedence of operators, 129 
predicting eclipses, 3 
prefix notation, 126, 132 
preindexed indirect addressing, 408, 
425 

primitive logic gates, 15, 36 
printers, 176 


product (result from multiplication), 
106 

profiler application, 147 

program counter (PC), 44, 237-243 

programs 

assembling programs, 166 
calculator framework, 375-382 
creating programs, 164 
debugging programs, 201 
editing programs, 164 
loading programs, 166 
running programs, 166 
testbench program, 277-297 
proof of the pudding, 152 
Protel2004, 151,433 
pseudoinstructions, 165 
punctuation, 6 
characters, 175 
purging memory, 191 
PUSHA (instruction), 48 
pushing 

accumulator onto stack 
after call to subroutine, 58 
before call to subroutine, 57 
status register onto stack, 50 
PUSHSR (instruction), 50 

Q 

quotient (result from division), 

113 

R 

radix, 9 

complement, 84 
radix-10, 9 

Rahn, Johann, 107, 115 
RAM, 24, 25, 27 

random access memory (RAM), 24, 
25 

range (vector notation), 160 
ratios (indicating with “:”), 115 
reading from keypad, 185, 188 
read-only memory (ROM), 24, 25 
read-write memory (RWM), 26 
reason behind the madness, 100 
reciprocal, 187 
Recorde, Robert, 78 
rectangles (flowchart actions), 161 
recursion, 63, 64 



INDEX 453 


recursive subroutines, 63, 267-274 
end conditions, 64 
mutually recursive, 64 
Redin, James, 144, 435 
red woolly socks, 2 
register, 159, 185 
remainder 

result from division, 113 
result from subtraction, 83 
Renaissance, the, 4, 74 
Renan, Ernest, 1 
rending of clothing, 73 
reset 

button, 173, 209 
mode, 160, 209 
power-on reset, 25 
signal, 24 

restoring division algorithm, 354 
return address, 54 

popping return address, 61 
pushing return address, 62 
reverse Polish notation, 132, 409 
Rhonius, Johann, 107 
ripple carry adder, 76 
Robert 

McCloskey, 183 
Recorde, 78 
rocket scientist, 2 
ROLC (instruction), 41, 42, 43 
ROM, 24, 25, 27 
Roman numerals, 9 
Rooney, Andy, 23 

rotate instructions (ROLC, RORC), 
41,42,43 

carry flag, effect on, 41, 42 
RORC (instruction), 41, 42, 43 
rounding, 117, 357-359 
bankers’ rounding, 118, 357 
chopping, 107 
round-ceiling, 119 
round-down, 117 
round-floor, 119 
round-half-down, 118 
round-half-even, 118, 357, 
367-369 

round-half-odd, 118 
round-half-up, 118 
round-up, 117 
stochastic rounding, 119 


RPN, 132, 409 
RTS (instruction), 54 
several in one routine, 56 
rules (labels), 171 
Run 

button, 166, 173, 209 
mode, 209 

running programs, 166 
RWM, 26 

Rx (button / code / key), 187 
S 

SAIL, 216 

Sartre, Jean-Paul, ix 
scalar notation, 76, 160 
Schickard, Wilhelm, 4 
score (meaning 20), 9 
scrambling memory, 181 
secret squirrel sauce, 406 
self-modifying code, 64 
semiconductor switches, 15 
serving plates, pile of, 46 
setting bits (using OR), 37 
Setup > System Clock, 197 
Shakespeare, William, 7, 35 
sharing subroutines with others, 152 
sharp (“#”), 165 
shift-and-add 

binary multiplication, 109 
decimal multiplication, 108 
shift instructions (SHL, SHR), 38-40 
arithmetic shifts, 39 
carry flag, effect on, 39, 40 
logical shifts, 40 
shilly-shallying, 179 
SHL (instruction), 38-40 
carry flag, effect on, 38-40 
SHR (instruction), 38-40, 195 
carry flag, effect on, 38-40, 196 
shriek character (“!”), 183 
sign bit 

signed binary numbers, 98 
sign-magnitude binary numbers, 
97 

sign correction 

following division, 117, 359, 369 
following multiplication, 112, 339, 
346 

signed binary numbers, 98, 99 


adding, 101 
dividing 

by shifting right, 113 
long division, 116 
rounding, 117-119 
multiplying 

by shifting left, 105 
shift-and-add, 109 
subtracting, 102 

sign-magnitude representations, 96 
silicon chips, 149 
Sin (button / code / key), 187 
sine, 187 

single-stepping, 210 
sixteen hexadecimal digits, 18 
skeleton file, 221 
slaves 

to calculation, 23 
to fashion, 2 
slide rule, 107 
small stones, 8 
Smith notation, 132 
Smithsonian Institution, 5 
snails (and mice), 130 
lethargic snails, 197 
sneering contemptuously, 73 
socks, red woolly, 2 
solidus, 115 
soundly chastised, 66 
source code / file / program, 161, 206 
SP (stack pointer), 46, 47, 255-259 
space capital of America, 2 
special characters, 175 
spelling, 6 

spokesman, U.S. State Dept., 183 
spring (a big one), 46 
square, 11, 187 
perfect square, 11 
root, 187 

squirrels, secret sauce, 406 
SR (status register), 177 
bits / flags, 177 
pushing onto stack, 50 
popping off stack, 50 
STA (instruction), 165 
stack 

concept of, 46, 47 
overflow, 52 

pointer (SP), 46, 47, 255-259 
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stack (continued) 
postfix notation, 127 
subroutines, 52 
underflow, 52 
using the stack, 255-259 
wrong way round, 51 
Stanford Artificial Intelligence Lab., 
216 

status 

bits / codes / flags, 177, 211 
register (SR), 177 
bits / flags, 177 
pushing onto stack, 50 
popping off stack, 50 

Step 

button, 173, 209 
mode, 209 

Step Reckoner, 4, 107 
stochastic rounding, 119 
stones, 8 
string 

generator utility, 216, 217 
of characters, 202 
structured numbers, 143, 435 
BCD representations, 146 
stub statements, 378 
STX (start of text) code, 176 
_SUB (subroutine) 
signed 16-bit, 329-332 
unsigned 16-bit, 311-315 
SUB (instruction), 91 
carry flag, effect on, 91 
SUBB (instruction), 94 
SUBC (instruction), 94 
carry flag, effect on, 95 
subroutines 
_ADD (add) 

signed 16-bit, 327-329 
unsigned 16-bit, 299-309 
CHK2NEG (check if too negative), 
324-326, 388 
concept of, 52 

DISPERR (display error), 292-294, 
386-387 

DISPNUM (display number) 
decimal, 395-403 
hexadecimal, 288-292 
FMULT (factorial multiplier), 273 
GETNUM (get number) 


decimal, 389-394 
hexadecimal, 280-288 
GETSTUEF (get string), 383-386 
JSR instruction, 53 
_MULT (multiply), 339-349 
multiple 

calls to same routine, 56 
return points in routine, 56 
_NEG (negate), 317-321 
nested subroutines, 63, 264-265, 
402 

_NOTYET (not implemented), 
387 

parameters, passing into, 59 
passing parameters into, 59 
pushing accumulator 

after call to subroutine, 58 
before call to subroutine, 57 
recursive subroutines, 63, 267-274 
end conditions, 64 
mutually recursive, 64 
return address, 54 

popping return address, 61 
pushing return address, 62 
RTS instruction, 54 

multi-copies in one routine, 56 
sharing with others, 152 
stub statements, 378 
_SUB (subtract) 

signed 16-bit, 329-332 
unsigned 16-bit, 311-315 
using subroutines, 261-265 
subscripts, 13, 18 
subtraction, subtracting 
binary numbers 

ones complement, 86 
signed, 102 
twos complement, 87 
unsigned, 82, 86, 87 
decimal numbers 
American borrow, 82 
English borrow, 83 
nines complement, 84 
tens complement, 85 
multibyte subtractions, 94 
symbol (-), 88 
subtrahend, 83 
suck it and see, 115 
sum (result from addition), 72 


summary, instruction set, 429-431 
summer-solstice card, 3 
SWAP PAWS, 267 
system clock, modifying, 197 

T 

Tan (button / code / key), 187 
tangent, 187 
tap-dancing, 82 
tattoo, 201 

teachers (resources), 434 
teeth, gnashing of, 73 
Teletype terminals, 176 
tens complement, 84, 85 
testbench program, 277-297 
testing for -32, 768, 323-326 
Teutsche Algebra, 107, 115 
Texas Instruments (TI), 5 
The Whetstone of Witte, 78 
Thomas Harriot, 94 
thought experiments 
4-bit division, 351-359 
4-bit multiplication, 333-339 
TI (Texas Instruments), 5 
time travelers, 2 
tingle of anticipation, 406 
toes and fingers, counting on, 8 
Tools > Assembler, 164 
tossing coins, 119 
transistors 
invention of, 4 
using to build computers, 15 
true (logic value), 36 
truth tables 
1-bit adder, 74 

AND, OR, and XOR gates, 36 
Tukey, John Wilder, 13 
twos complement, 87, 100 
shortcut, 87, 88 

U 

uglification, 69 
unary operator (+/-), 125 
underflow 
condition, 313 
stack underflow, 52 
unsigned binary numbers, 16, 70 
adding, 71, 72 
subtracting, 82, 86, 87 
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uppercase, 172 
usage models, 125 
using 

subroutines, 261-265 
the stack, 255-259 
wires to represent numbers, 15 
U.S. State Dept, spokesman, 183 

V 

vector notation, 75, 159 
verbal numbers, 143, 435 
BCD representations, 146 
very naughty, 66 
Vikings, 2 
vinculum, 115 
voltage levels, 15 
volts, 15 

W 

warehouse, 46 

warrior chieftain, 3 

warriors, fearsome, 2 

website (for DIY Calculator), 435 

West, Mae, 123 

Whetstone of Witte, The, 78 


whole numbers, 70 
Widmann, Johann, 74, 88 
wildest dreams, 403 
Wilhelm Schickard, 4 
WiUiam 

Oughtred, 107 
Shakespeare, 7, 35 
Window > View List File, 205 
Window > View Source File, 216 
wires, using to represent numbers, 15 
Wonderland, Alice in, 69 
woolly socks, red, 2 
words, memory, 28 
worst-case conditions, 349 
writing to 
LEDs, 193 

main display, 173, 178 
X 

xA2 (button / code / key), 187 
xA3 (button / code / key), 187 
xAy (button / code / key), 187 
X (index register), 45, 202, 245-254 
accessing contents, 249-252 
as a counter, 252-254 


Xnumbers, 145, 435 
XOR 

instruction, 37 
logic gate, 36 
overflow (O) flag, 104 
sign of result, 112 

Y 

yogalflump (an imaginary beast), 
456 

Z 

Z (zero) status bit, 177, 178 
effect of CMP A, 191 
JNZ instruction, 180 
JZ instruction, 180 
zero 

as an actual value, 9 
goats, 9 

status bit, 177, 178 
effect of CMPA, 191 
JNZ instruction, 180 
JZ instruction, 180 
the concept of, 3 



